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I. IH TBO DDC TION 



Around 1964 a new term appeared in the computer litera- 
ture to denote a new concept. The term was "database," and 
it was going to play a highly significant role in an organi- 
2 ation's information system. The information system 
supports the organization's functions, maintaining the data 
for these functions and assisting users to interpret the 
data for decision mating. The database becomes an important 
tool in this process; it is the container of the data in the 
information system. 

In many information systems, database denotes collec- 
tions of data shared by end-users of computer systems. Users 
who make decisions obtain data by accessing the database and 
then recording their decision in it. Easy access to a 
variety of data, from a number of locations enables the 
information system to guickly respond to the needs of deci- 
sion makers within the organization, whereas poor access can 
of course hinder rapid response. If the data are not 
readily available, decisions may be either delayed unneces- 
sarily or made with incomplete data, leading to possible 
system malfunction in the future. 

The flexibility of the database structures is a very 
important feature to meet changing organizational needs. As 
new functions arise in an organization, new decisions fellow 
in their wake. Since the database will need to store new 
data and accommodate new relationships to support the new 
decisions, it must include facilities to allow such changes 
to be easily made. £Bef. 1:pp- 1~3] 

Today, computer applications in which many users at 
terminals concurrently access a database are called "data- 
base applications" [Bef. 2]. A significant new kind of 



software, the database management system, or DBMS, has 
evolved to facilitate the development of database applica- 
tions, The development of DBMS, in turn, has given rise to 
new languages, algorithms, and software techniques which 
together make up what might be called a database technology. 

Database technology has been driven by, and to a large 
extent distinguished from other software technologies by the 
following broad user requirements. 

.Data consolidaticn 
.Data independence 
, .Data protection 

In the years ahead, database systems will become 
increasingly widespread and increasingly important. At 
present, however, they represent a new and relatively unexp- 
lored field, despite the fact that the number of systems 
installed or under development is growing rapidly. 

The primary goal of this thesis is to present the design 
steps of a particular database system, design criteria, and 
the elements of the database system which provide designers 
with the ability to evaluate databases against these 
criteria. The second objective of this thesis is to show the 
implementation of that database system which controls and 
executes the transactions written in a model-based database 
language such as Data Definition Language (DDL) and Data 
Manipulation Language (DML) . Finally, the third objective of 
this study is to introduce essential features of the main- 
tainability, administration, and security of a database 
management system. 

Chapter II describes the basic concepts of database, 
including the definition of a DBS, its components, its 
architecture, and some advantages/disadvantages. Chapter III 
briefly reviews the design objectives and techniques of a 
database and describes logical and physical database design. 
Chapter IV also briefly addresses database models which can 
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te used to form a logical framework of a database and to 
support further design phases and/or to create intended 
database structure which will be implemented after the 
completion of design phases. Chapter V introduces, in 
detail, the Semantic Database Model for a personnel assign- 
ment database. Chapters VI and VII describe the design of 
the personnel database by using the Relational Database 
Model approach which is one of the three database models. In 
addition rules, design criteria, and important operations 
associated with this nodel are given. Chapter VII also shows 
how the designer can transform the SDM model which has been 
designed for a personnel database system into a relational 
database model. The INGRES Database Management System which 
is available today is discussed in Chapter VIII. Chapter IX 
demonstrates the implementation of the relational database 
system which is implemented on the VAX computer systems by 
using the ORACLE Relational DBMS. Chapter X describes the 
functions of a DBMS, such as security features, maintain- 
ability, and concurrent processing control. Finally, conclu- 
sions and recommendations based on our research are 
presented in Chapter XI. 
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II. BASIC CONCEPTS OF D ATABASE 



A. DEFINITION OF A lATABASE SISTEfl 

The simplest definition of a database might be that a 
database is a collection of facts or a repository for stored 
data which is both in tegrated and share d. By "integratsd" 
we mean that the database may be considered as a unification 
of several otherwise distinct data files, with any redun- 
dancy among those files partially or wholly eliminated. By 
''shared” we mean that individual pieces of data in the data- 
base may be shared among several different users, in the 
sense that each of those users may have access to the same 
piece of data. The term "shared” is also extended to cover 
concurrent sharing: that is, the ability for several users 
to be accessing the database at the same time. [Hef. 3:pp- 
3-7] 

R.H, Engles [Ref. 4] refers to the data in a database as 
"operational data,” distinguishing it from input data, 
output data, and other kinds of data. Thus, a modified 
version of Engles' original definition of database is that a 
database is a collection of stored operational data used by 
the application systems of some particular enterprise. 
"Enterprise” is simply a convenient generic term for any 
reasonably self-contained commercial, scientific, technical, 
or other organization. Any enterprise must necessarily 
maintain a large amount of data about its operation. This is 
its "operational data,” such as product data, account data, 
military personnel data etc. 

In recent years, technology improved to the point where 
it became feasible tc design, build, and operate large-scale 
collections of data in a computer environment. In other 
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words, organizations realized that data were a valuable 
resource and needed to be centrally managed. The concept of 
a database has thus emerged fully only in recent years. A 
database can also be defined as a computerized collection of 
stored operational data that serves the needs of multiple 
users within one or more organizations £Eef, 5:pp. 3-17]. A 
Xey point is that the database is an integrated resource to 
be used by all members of the organizations who need infor- 
mation contained in it. 

Since the database is an integrated and shared resource 
for multiple users within an organization, it should be 
managed for the organization’s benefit and from its view- 
point, not by individual users. Thus, two additional 
concepts have been developed to solve the problem of 
controlling and managing the organization’ s database 
resource. Initially, software was developed to provide a 
common interface between all users and the integrated data- 
base. A common interface promotes privacy and data integ- 
rity. Also, users cannot store information implicitly and 
must use and modify data in a manner consistent with the 
organization’s viewpoint. The software, known as a database 
management system, allows computer control of the data 
resource. A database management system (DBMS) is a collec- 
tion of software tools and access methods which enables the 
users to store facts about real-world objects and the rela- 
tionships between these objects, and to manipulate those 
facts by issuing queries in content-addressable form. In 
short, a DBMS is a generalized tool for manipulating a data- 
base [Ref. 5:pp. 3-17] ; it is made available through 
special software for the interrogation, maintenance, and 
analysis of data. 

The second concept is that of the database administrator 
(DBA) . Ihe DBA can be thought of as one or more individuals, 
possibly aided by a staff, who manage the organization’s 



database resource [Be£. 5:pp. 3-17], or are responsible for 

overall control of the database system. The DBA’s responsi- 
bilities include the following [Eef. 3:pp. 25-26]. 

•Deciding the information content of the database. 

.Deciding the storage structure and access strategy. 

.Liaising with users. 

.Defining authorization checks and validation procedures. 

.Defining a strategy for backup and recovery. 

.Monitoring performance and responding to changes in 

reguirements. 

We can clearly see the reason why an organization should 
choose to store its operational data in an integrated data- 
base. A database system provides the organization with 
centralized control of its operational data which is one of 
its most valuable assets. This is in sharp contrast to the 
situation that prevails in many organizations today, where 
typically each application has its own private files so that 
the operational data is widely dispersed, and is therefore 
probably difficult tc control. 

E. CCHECHENTS OF A lATABASE SISTEM 

A database system consists of four major components: 
data, hardware, software, and users. Fig 2.1 shows a greatly 
simplified view of the major components of a database 
system. 

1 . Da ta 

The data stored in the system is partitioned into 
one or more databases. For tutorial purposes it is usually 
convenient to assume that there is just one database, 
containing the totality of all stored data in the system. 

According to standard usage in the computer 

industry, bits are grouped into bytes or characters. 
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Figure 2. 1 Simplified View of a Database System. 

characters are grouped into fields, and fields are grouped 
into records. A collection of records is called a file. At 
this point, we cannot say that a database is a collection of 
files. A database is a collection of ’’integrated" files and 
relationships among records in those files. Database 
processing differs from file processing in which the struc- 
ture of the files is distributed across the application 
programs and each file is considered to exist independently. 
Cn the other hand, the database is self-describing because 
it contains, within itself, a description of its structure. 
Another difference between file processing and database 
concerns the term file. For file processing, the records in 
a file are usually grouped together physically. For database 
processing, the logical collection of records probably does 
not exist as a physical collection. In database processing, 
there are logical files, or collections of records having 
meaning to users, and physical files, or collections of 
records cn physical devices. 
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2. Hardware 



In general, database applications do not require 
special hardware. It consists of direct access storage (or 
secondary storage) devices (disks, drums, etc.) on which the 
database resides, together with the associated devices, 
control units, channels, and so forth. It is assumed that 
the database is too large to be stored in its entirety 
within the computer’s primary storage. 

In 1982, a new term appeared and several vendors 
announced new products called "database machines" [Ref. 6;p. 
8]; These machines are special purpose computers that 
perform database processing functions. According to this 
type of architecture, the main frame or host computer sends 
requests for service and data over a channel to the database 
machine. The machine processes the requests and sends 
results, messages, or data back to the main computer. Thus 
database processing can be performed simultaneously with 
applications processing. The actual ef f ectiveness ’ of such 
machines is under investigation. If substantial processing 
efficiencies can be proved at a reasonable cost, then data- 
base machines will become important. Hardware aspects of the 
system form a major topic in their own right; the problems 
encountered in this area are not peculiar to database 
systems, and those problems have been very thoroughly inves- 
tigated and documented elsewhere. Thus, this thesis is not 
concerned with hardware aspects of the system. 

3 , Sof tware 

The database management system or DBHS is a layer of 
software which provides the interface between the physical 
database itself (i.e,, the data as actually stored) and the 
users of the system. All requests from users for access to 
the database are handled by the DBHS. One general function 
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provided by the DBMS is the separation of database users 
from hardware- level detail. In other words, the DEHS 
provides a view of the database that is elevated somewhat 
above the hardware level, and supports user operations (such 
as "get the OFFICER record for officer Buyukoner") that are 
expressed in terms of that higher-level view. This function, 
and other functions of the DBMS, will be discussed in detail 
later. 

Two types of programs involved in database 
processing are the Operating System (OS) and Communications 
Control Program (CCP). The operating system is a set of 
programs which controls the computer’s resources. In a 
sense, the OS can be viewed as the glue that holds all of 
the other programs together. Communications control program 
(CCP) performs ccmmunications-oriented tasks. On-line 
processing requests or transactions are provided by users at 
terminals. The requests are received and routed by the CCP 
over communications lines. The CCP has several important 
functions: provides communications error detection and 
correction, manages terminal activity, routes messages to 
the correct next destination, and formats messages for 
various types of terminal equipment. The CCP also routes 
on-line input to the next level of programs which contains 
application programs and database utilities. The operating 
system and the CCP will not be discussed further in this 
thesis. 

4 . Dsers 

There are three broad classes of user being consid- 
ered: application programmers, end-users, and the database 
administrator (DBA). [Ref. 3:p. 6] 

The application programmer is responsible for 
writing application programs that use the database, typi- 
cally in a high-level language such as COBOL or PL/I. These 
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application programs are used with the data for retrieving 
information, creating new information, and deleting or 
changing existing information. The programs themselves may 
be conventional batch applications, or they may be "on-line” 
programs that are designed to support an end-user inter- 
acting with the system from an on-line terminal. 

The end-user can access the database from a 
terminal. An end-user may, in general, perform all the func- 
tions of retrieval, creation, deletion, and modification by 
employing a query language provided as an integral part of 
the system, or by invoking a user-written application 
program that accepts commands from the terminal and in turn 
issues requests to the DBMS on the end-user’s behalf. 

The database administrator, or DBA mentioned earlier 
in this Chapter, is the person (or group of persons) respon- 
sible for overall control of the database system. The func- 
tion of the DBA staff is to serve as a protector of the 
database and as a focal point for resolving users' 
conf 1 lets. 

C. ADVAHTAGES AND DISADVANTAGES OF DATABASE PEOCESSING 

The main advantage of database processing is included in 
its definition given previously. Integrated and shared data 
offers those important advantages. Database processing 
allows mere information to be produced from a given amount 
of data. Secondly, the amount of redundancy in stored data 
can be minimized. In other words, the elimination or reduc- 
tion of data duplication allows data to only be stored once. 
As a result, this saves file space, and to some extent, can 
reduce processing requirements. [Ref. 6:pp. 3-8], and 
[Ref. 7:pp. 1-16] 

As mentioned earlier, centralized control of the opera- 
tional data in a database provides the following advantages 
[Ref. 3:pp. 10-12]. 
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1 . Avoidance of I nconsist ency 



This is reallj a corollary of the above point. If a 
given fact about the real world is represented by two 
different entries in the database and the redundancy is not 
controlled, then there will be some occasions for which the 
two entries will not agree (that is, when only one has been 
updated) . At such times the database is said to be inconsis- 
tent. In this case, the database produces incorrect or 
conflicting information. If the redundancy is controlled, 
then the system could guarantee that the database is never 
inconsistent as seen by the user, by ensuring that any 
change made to either of the two entries is automatically 
made to the other. This process is known as propagating 
updates (the term '’update” is used to cover all the opera- 
tions of creation, deletion, and modification) . 

2 • Sha red Data 

The concept of shared data was discussed in Section 

A. 



3- E nforcemen t cf Standards 

The applicable standards, which may include any or 
all of the following: installation, company, industry, and 
national standards, are followed in the representation of 
the data. Standardizing stored data formats assists in data 
interchange or migration between systems. 

4 . A pplic a tio n of ^cur ity Restrictions 

The DBA can define authorization checks tc be 
carried out whenever access to sensitive data is attempted 
(see Chapter X for more detail) . 



Maintenanc e of Data 

The problem of integrity is the problem of ensuring 
that the data in the database is accurate. Inconsis tency 
between two entries representing the same "fact" leads to a 
lack of data integrity (which can occur only if redundancy 
exists in the stored data). It is essential to point out 
that data integrity is even more important in a database 
system than in a "private files" environment, because the 
database is shared. Centralized control of the database 
supports data integrity. 

6* Balancing of Conflicting Requi r e ments 

Knowing the overall requirements of the enterprise, 
the DBA can structure the database system to provide an 
overall service that is "best for the enterprise," 

The cost of database processing may become a major 
disadvantage. It can be expensive. The DBMS may need so much 
primary storage that additional storage must be purchased. 
Even with more storage, it may get exclusive control of the 
CPO, thus forcing the user to upgrade to a more powerful 
computer. [Ref. 6:pp. 3-8] 

Once the database is implemented, operating costs 
for seme systems will be higher. For example, sequential 
processing will never be done as fast in the database envi- 
ronment, since it causes excessive overhead. 

large amounts of data in different formats can be 
interrelated in the database. Both the database system and 
the application programs must be able to process these 
structures. This requires more sophisticated programming, 
takes time, and requires highly skilled programming 
personnel. Thus, the complexity is another important disad- 
vantage of database processing. Backup and recovery also 
increases complexity and are more difficult in the database 
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environment to carry out. Another reason for this is that 
databases are often processed by multiple users concur- 
rently. Determining the exact state of the database at the 
time cf failure may be a problem. Given that, it may be even 
more difficult to determine what should be done next. 

Another disadvantage is that integration, and hence 
centralization, increases vulnerability. A failure in one 
component of an integrated system can cause the entire 
system to 'fail. This event is especially critical if the 
operation of the user organization depends on the database. 

To avoid these potential drawbacks a database 
management system (DBHS) should satisfy the following objec- 
tives [Bef. 7:pp. 13-14] : 

.Different functions of an enterprise can be served 
effectively by the same DBMS. 

.Redundancy in stored data can be minimized. 

.Consistent information can be supplied for the decision- 
making process. 

.Security controls can be applied. 

.Application programs can be developed, maintained, and 
enhanced faster and more economically, with fewer 
skilled personnel. 

.Physical reorganization of the stored data is easy. 

.Centralized conticl of the database is possible. 

.Easier procedures for computer operations can be 
established. 

D. AN ABCHITECTDRE PCH A DATABASE SYSTEM 

An architecture fcr a database system is illustrated in 
Fig. 2.2 [Bef. 3:p. 20]. This picture presents a framework 
which is extremely useful for describing general database 
concepts and for explaining the structure of individual 
systems, and it is ir broad agreement with that proposed by 
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the ANSI/SPIRC Study Group on Data Base Management Systems 
[Ref. 8]. 

Ihe architecture is divided into three general levels: 
internal, conceptual, and external. Generally speaking, the 
external level is the one closest to the users; that is, the 
one concerned with the way in which the data is viewed by 
individual users. The internal level is the level closest to 
physical storage; that is, the one concerned with the way in 
which the data are actually stored. The conceptual level is 
a bridge or "level of indirection" between the other two. 
There may be many "external views," each consisting of a 
more or less user oriented logical representation of some 
portion of the database (such as logical records and 
fields), and there may be a single "conceptual view," 
consisting of a sinilarly logical representation of the 
entire database. Likewise, there will be a single "internal 
view," representing the total database as actually stored. 

The three levels are also defined as levels of abstrac- 
tion and named in the specification of a database structure: 
the conceptual or enterprise administrator view, the imple- 
mentation view of the applications programmer or end user, 
and the physical view of the systems programmer/analyst 
[Ref. 5:pp. 3-17], The external level, conceptual level, 
and internal level in the ANSI/SPARC model correspond to the 
implementation level, conceptual level, and physical level 
in the levels of abstraction, respectively. Figure 2.3 
shows these three levels of abstraction and some of their 
primary components. 

It should be obvious that between the computer, dealing 
with tits, and the ultimate user, dealing with abstractions 
such as military units or assignment of personnel to a divi- 
sion, there will be many levels of abstraction. It should be 
emphasized that only the database actually exists at the 
physical level- We may view the physical database itself at 
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Figure 2.2 Database System Architecture. 

several levels of abstraction, ranging from that of records 
and files in a programming language such as Pascal, through 
the level of logical records, as supported by the operating 
system underlying the DBMS, down to the level of tits and 
physical addresses on storage devices. We may also view the 
conceptual database as an abstraction of the real world 
pertinent to an enterprise. J.D. Ullman [Ref. 9:pp. 5-9] 
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Figure 2.3 Levels of Abstraction in a Database System, 



emphasizes that a view (or external view) is an abstract 
model of a portion of the conceptual database. As an example 
of the utility of views, the army may provide a computerized 
personnel assignment department, consisting of data and a 
collection of programs that deal with officers and military 
units. These programs, and the people who use them, do not 
require Xncwledge concerning personnel files or the assign- 
ment cf officers to units. The personnel department may 
need to know about assignments, units, and aspects of the 
personnel files (e. g., which officers are qualified to 
assign to unit X) , but does not need to know about personnel 
salaries. Thus, there may be one view of the database for 
the personnel department and another for the finance 
department. 



"In a sense, a view is just a small conceptual database, 
and it is at the same level of abstraction as the 
conceptual database. However, there are senses in which 
a view can be "more abstract” than a ccnceptual data- 
base, as the data dealt with by a view may be construc- 
taile from the ccnceptual database but not actually 
present in that database.” [Eef. 9:p. 7] 
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Figure 2.2 illustrates the several components of the 
architecture in more detail. Next, we will examine these 
components. 

Each user has a language at his or her disposal. For the 
application programmer it will be a high-level programming 
language, such as Pl/I or COBOL; for the terminal user it 
will be either a guery language or a special-purpose 
language supported by an on-line application program to meet 
the user’s reguirements. Each of those languages is known as 
’’host language.” The term "data sublanguage (DSL)” is a 
subset of the host language that is concerned with database 
objects and operations. In other words, the DSL is embedded 
in a host language. Multiple host languages and multiple 
DSLs may be supported by a given system. In principle, any 
given data sublanguage is really a combination of two 
languages [Ref- 3:pp. 17-25], a data definition language 

(DDL), which provides for the definition or description of 
database objects, and a data manipulation language (DML) , 
which supports the manipulation or processing of such 
objects. In most systems today the data sublanguage and the 
host are very loosely coupled. That is, the definitions 
written in DDL are completely outside the application 
program. 

An external view is the content of the database as it is 
seen by some particular user. In general, an external view 
consists of multiple occurrences of multiple types of 
external records [Eef. 3:pp. 17-25]. An external record 

refers to a "logical record” which is not necessarily the 
same as a stored record (see Section E of this Chapter) . 

Each external view is defined by means of an external 
schema, which is made up of definitions of each of the 
different types of external records in that view. The term 
"view" is used for a set of record occurrences and the term 
’’schema” is used for the definition of that view. The DDL 
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portion of the data sublanguage is used to write the 
external schema. That DDL is sometimes called an external 
DDL. 

The conceptual view is a representation of the entire 
information content of the database in a form that is some- 
what abstract in comparison with the way in which the data 
are physically stored. The conceptual view is composed of 
multiple occurrences of multiple types of conceptual 
records. It is more desirable to consider ’'entities," and 
"relationships" instead of dealing in terms of "conceptual 
records." A conceptual record is not the same as either an 
external record or a stored record. For example, the concep- 
tual view may consist of a collection of branch record 
cccurrences plus a collection of military personnel record 
occurrences plus a collection of course record occurrences, 
and so on. The conceptual view is defined by means of the 
conceptual schema, which includes definitions of each of the 
several types of conceptual records. The conceptual view is 
a view of the total database content, and the conceptual 
schema is a definition of this view. The conceptual schema 
is written using another DDL called conceptual DDL. It is 
intended that the definitions in the conceptual schema 
include many additional features, such as the authorization 
checks and validation procedures, and these definitions must 
not involve any considerations of storage structure or 
access strategy. In other words, there must not be any 
reference to stored field representations, physical 
sequence, hash-addressing, indexing, or any other storage/ 
access details. At this level, the situation allows the 
conceptual model to be "data independent" which will be 
discussed in the next Section. 

Some authorities would suggest that the fundamental 
objective of the conceptual schema is to describe the entire 
enterprise; not just its operational data, but also how that 
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data is used, how the data flows within the enterprise, what 
the data is used for at each pcint, what audit controls are 
to he applied at each point, and so on. 

The internal view or physical level of the architecture 
is a very low-level representation of the entire dataiase. 
It consists of multiple occurrences of multiple types of 
stored records (the ANSI/SPSEC refers to this term as 
"internal record") . The internal view is defined by means of 
the internal schema, which not only defines the various 
types of stored records but also specifies what indexes 
exist, how stored fields are represented, what physical 
sequence the stored records are in, and so on [Bef. 3:pp. 
17-25]. Another data definition language (the internal DDL) 
is used to write the internal schema. It is convenient to 
use the tern "stored database" in place of "internal view," 
and "storage structure definition" in place of "internal 
schema. " 

Two levels of mapping are shown in Fig. 2.2 The 
conceptual/internal mapping describes the correspondence 
between the conceptual view (or data model) and the stored 
database; it specifies how conceptual records and fields map 
into their stored counterparts. If the structure of the 
stored database is changed, the conceptual/internal mapping 
must be changed accordingly, so that the conceptual schema 
may remain invariant. For example, if a change is made to 
the storage structure definition of the database, the 
effects of such a change must be contained below the concep- 
tual level, so that "data independence" can be accomplished. 

An external/conceptual mapping describes the correspon- 
dence between a specific external view and the conceptual 
view. In general, the same kind of differences may exist 
between these two levels as may exist between the conceptual 
view and the stored database. For example, records may be in 
different sequences, fields may have different data types. 



2S 



and so on. Different external views may overlap. That is, 
any Dumber of external views may exist at the same time and 
any number of users may share a given external view. Some 
systems allow the definition of one external view to be 
expressed in terms of others without always requiring an 
explicit definition of the mapping to the conceptual level. 
If various external views are strictly related to one 
another, this will be a very useful feature of the system. 

Eeferring again to Fig. 2.2, there still remain three 
components of the architecture: the database management 

system (EBHS) , the database administrator (DBA) , and the 

user interface. The DBMS is the software that handles all 
access to the database. The basic steps that occur in a DBMS 
are the following [Ref. 3:pp, 17-25] : 

1. A user issues an access request, using some partic- 
ular data manipulation language, 

2. the DBMS intercepts the request and interprets it, 

3. the DBMS inspects, in turn, the external schema, the 
external/conceptual mapping, the conceptual schema, 
the conceptual/internal mapping, and the storage 
structure definition, and 

4. the DBMS performs the necessary operations on the 
stored database. 

For example, assume that a user wishes to retrieve a 
particular external record occurrence. In general, the DBMS 
must retrieve all required stored record occurrences, 
construct the required conceptual record occurrences, and 
then construct the required external record occurrence. At 
each step, data type or other conversions may be necessary. 
Whenever a retrieval request occurs, fields will be required 
from several conceptual record occurrences, and each concep- 
tual record occurrence, in turn, may require fields from 
several stored record occurrences. 
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The database administrator (DBA) / previously discussed 
to some extent, controls the overall database system. Ke 
will only mention the utilities and tools which are required 
to achieve the DBA’s tasks. Such utilities would be an 
essential part of a database system. For instance, loading 
routines, reorganization routines, journaling routines, 
recovery routines, and statistical analysis routines may be 
included as utilities. One of the most important DBA tools 
is the "data dictionary" {not shown in Fig. 2.2). The data 
dictionary is effectively a database in its own right (that 
is, descriptions of ether objects in the system) . In partic- 
ular, all the various schemas (external, conceptual, 
internal) are physically stored in both source and object 
form in the dictionary. A comprehensive dictionary will also 
include cross-reference information, showing, for example, 
which programs use which pieces of data, which departments 
require which reports, and so on. It is possible to query 
the dictionary just like any other database, so that the DBA 
can easily discover which programs are likely to be affected 
by some change to the system. 

A data dictionary should help a database user in the 
following ways: [Ref. 7;pp. 20-21] 

.Communicating with the other users. 

•Ccntrolling the data elements in a simple and effective 
manner, that is, introducing new elements into the 
systems, or changing the definitions of the elements. 

.Reducing data redundancy and inconsistency. 

.Determining the impact of changes to data elements on 
the total database. 

.Centralizing the control of the data elements as an aid 
in database design and in expanding the design. 

The user interface, shown in Fig. 2.2, may be defined as 
a boundary in the system below which everything is trans- 
parent (invisible) to the user. Thus, the user interface is 
at the external level. 
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E. 



DATA INDEPENDENCE 



The concept of data independence may be easily utder- 
stood by first introducing its opposite. Currently, many 
applications are data-dependent . This means that the 
requirements of the application dictate both the way in 
which the data are organized in secondary storage and the 
way in which they are accessed, and, moreover, that knowl- 
edge cf the data structure and access method is built into 
the application logic. In this case, the application 
programmer has to knew the data format, the location of 
where the data is stored, and the access method which tells 
how the data is accessed. Changes in any of these items may 
affect the application program and result in other changes, 
since the details of these three points may be embedded into 
the application code. It is also likely that as the needs of 
the enterprise change, the format of the data may change, 
and the data set has to be expanded by adding information 
about different types of entities or additional information 
about existing entities. 

It is said that an application such as above is data- 
dependent because it is impossible to change the storage 
structure (how the data is physically stored) or the access 
method without affecting the application. For example, it 
would not be possible to replace an indexed sequential file 
by a hash-addressed file without making any changes to the 
appl icat ion. 

In a database system, there are at least two important 
reasons why applications must be data-independent 
[Eef. 3;pp. 12-17]. 

1. Different applications will need different views of 
the same data. 

2. The DBA must have the freedom to change the storage 
structure or access strategy (or both) in response to 
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chaBging reguirements without having to modify 
existing applications. For example, the enterprise 
may adopt new standards, application priorities may 
change, new types of storage device may become avail- 
able, and so on. 

If applications are data-dependent , such changes involve 
corresponding changes to programs, requiring programmers to 
spend an increasing percentage of their time in program 
maintenance and updating. 

Therefore, it is obvious that the provision of data 
independence is a major objective of database systems. S. 
Atre [Eef. 7:p. 17] defines data independence as 

••The ability to use the database without knowing the 
representation details. •' 

It can also be defined as the immunity of applications to 
change in storage structure and access strategy which 
implies that the applications concerned do not depend on any 
one particular storage structure and access strategy. In 
Section B, we have presented an architecture for a database 
system that provides a fundamental principle for achieving 
this objective. 

Data independence provides, at a central location, a 
solution to the problems discussed above. The individual 
application programmer is not required to change the appli- 
cation programs to accommodate changes in access method or 
location or format of the data. Unfortunately, it is diffi- 
cult to achieve full data independence in a database system, 
since a database design depends on the availability of the 
D3as software packages today, even with the best database 
design. The central location for reflecting changes in the 
storage structure and the access strategy should be anchored 
in the DBMS. The important point here is when, where, why, 
and who should specify the changes to the DBMS, and who 
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should control these changes? The DBA should ,of course, be 
given these responsibilities. 

The reasons for data independence are summarized as 
follows : 

”1. To allow the DBA to make changes in the content, 
location, representation and organization of a database 
without causing reprogramming of application programs 
which use the datatase. 

2. To allow the supplier of data processing equip- 
ment and software to introduce new technologies without 
causing reprogramming of the customer’s application. 

3. To facilitate data sharing by allowing the same 
data to appear to be organized differently for different 
application programs. 

h. To simplify application program development and, 
in particular, to facilitate the development of programs 
for interactive database processing. 

5. To provide the centralization of control needed 
by the DBA to insure the security and integrity of the 
database.” [Eef. 7;pp. 17-18] 

The levels of abstraction, mentioned in Section D above, 
from the external view to conceptual to internal view, 
provides two stages of ’’data independence.” In a well- 
designed database system, the internal schema can be modi- 
fied by the DBA without altering the conceptual schema or 
requiring a redefinition of the external schemas (or 
subschemas) , This independence is known as physical data 
independence. The advantage of physical data independence is 
that it permits ’’tuning” of the internal schema for effi- 
ciency while allowing application programs to run as if no 
change had occurred £Eef, 9:pp, 5-9]. 

The relationship between external views and the concep- 
tual view also gives a type of independence called logical 
data independence, aany changes to the conceptual schema can 
be made without affecting existing external schemas, and 
other changes to the conceptual schema can be made if the 
external/conceptual mapping is redefined by the DBA, Again, 
no change to the application programs is necessary 
[Ref. 9:pp. 5-9]. 
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In order to use standard terms as much as possible, it 
is essential to give some definitions for a database system. 



”A stored field is the smallest named unit 
stored in the database. The database, in 

contains many occurrences or instances of 
several types of stored fields. 



of data 
general , 
each or 



A stored record is a named collection of associated 
stored fields. A stored record occurrence or instance 
consists of a group of related stored field occurrences 
(and represents an association between them) . In most 
systems, the stored record occurrence is the unit of 
access to the database. 



A stored file is the (named) collection of all occur- 
rences of one type of stored record.'* [Bef. 3:p- 14] 



' We conclude this Chapter by pointing out that the DBMS 
can provide independence from: 

.underlying representations such as representation of 
numeric data, representation of character data, data 
encoding/decoding, and units for numeric data. 

.data structure such as materialization of computed 
fields, and structure of records and files. 
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III. AH 0TEB7IEW OF DATABAS E D ESIGN 
A. IHTBODDCTION 

Designing a datatase is a dif fic ult, complex and time- 
consuming process. Dnf ortunately, inadequate databases 
result because they cannot satisfy the present or future 
organizational requirements. 

The process of developing a database structure from user 
requirements is called database design. Many database 
designers have argued that there are at least two separate 
steps in the database design process: the design cf a 
logical database Structure which is processible by the DBMS 
and describes the user’s view of the data, and the selection 
of a physical structure that includes data representation or 
encoding, access methods, and physical clustering of data, 
ether than the logical/physical description, however, the 
overall structure of the design process has not been well 
defined, and even the logical/physical boundary has been 
open to considerable dispu-te. 

General information requirements include a statement of 
the objectives of the database system, definition of the 
data elements to be included in the database, and a descrip- 
tion of data element usage in the users' organizations. 
These requirements are not tied to any specific application; 
therefore, database structure design based on such require- 
ments is considered to be advantageous for long-term data- 
bases that must be adaptable to changing applications. 

Processing requirements consist of three distinguishable 
components; specific data items required for each applica- 
tion, the data volume (number of data occurrences), and 
processing frequencies in terms of the number of times each 
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application must be xun per unit time. DBMS specifications 
and the operating system/hardware configuration are also 
used by the designer. 

Performance measures and performance constraints should 
be considered by the designer. Typical constraints include 
upper bounds on response times to queries, recovery times 
from system crashes, or specific data needed to support 
certain security or integrity requirements. 

Two major results of the database design process are 
the complete database structure and guidelines for applica- 
tion programmers based on database structure and processing 
reguirements. 



E. raiAEASE SYSTEM LIFE CYCLE 

The database system life cycle is a convenient and 
useful framework from which to view the database system as 
it evolves over time. This framework provides an ordered 
background to the functions of a database administrator and 
is divided into three separate phases: analysis and design, 

database operation, and reorganization. These three phases 
are composed of the following steps: 

. Analysis and design phase 

1. Requirements formulation and analysis 

2. Conceptual design 

3. Implementation design 

U. Physical design 

. Database implementation and operation phase 

1. Database implementation 

2. Operation and monitoring 

. Reorganization phase (Modification and adaptation) 
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C. AHAllSIS AND DESIGN PHASE 



A stepwise design methodology for database designer or 
database administrator will be explained in this section. 
The general interconnections between steps are illustrated 
in Figure 3.1 [Eef. 5:p. 26]. 

^ • B equir e ments Formulati on and Analysis 

Eeguirements formulation and analysis constitute the 
most important step of the entire database design process, 
since most subseguent design decisions are based on this 
step. It is, however, the most poorly defined and time- 
consuming step of the entire process. 

Contemporary database applications are very broad 
and very sophisticated. Many diverse applications may use 
the same integrated database. The design of a database to 
support all the applications becomes very complex. A design, 
without sufficient information to support the analysis, will 
not be valid. 

The major task is collecting information content and 
processing reguirements from all the identified and poten- 
tial users of the database. Analysis of the reguirements 
ensures the consistency of users* objectives as well as the 
consistency of their views of the organization's information 
flow . 

This activity includes the establishment of organi- 
zational objectives, derivation of specific database 
reguirements from those objectives or directly from manage- 
ment and nonmanagement personnel, and documentation of those 
reguirements in a form that is aggreeable to both end users 
and database designers. The technigue used is personal 
interviews with various levels of management and key 
employees involved in the processing of data and services in 
the organization. £Bef. 5:p. 25]- 
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Figure 3.1 Basic Database Design Steps- 
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There is a need for corporate requirements analysis 
in the requirements formulation and analysis step. Data 
items and their relationships must be defined and conflicts 
are at least recogni 2 ed, if not resolved, during corporate 
requirements analysis. 

Different departments use different names for the 
same things, and the same names for different things, so 
that a preliminary common view of data and processes must be 
available before later steps can provide reliable results. 
Such a common view can be derived only in cooperation with 
users. However, this common view will not necessarily 
resemble the final database structure. In conclusion, there 
are two design constraints for this step; 

.accurately modeling real world requirements 
.aggregating individual views. 

2 . Concept ual Design 

Conceptual design deals with information independent 
of any actual implementation (i.e. any particular hardware 
or software system) . The main purpose of conceptual design 
is to represent information in a form that is comprehensible 
to the user independent of system specifics, but implemen- 
table on several systems. The result of conceptual design is 
called the conceptual schema because it is a representation 
of the user's "world” view and independent of any DBMS soft- 
ware or hardware con sider ations. 

This step results in a high-level representation of 
diverse users’ information requirements such as an entity- 
relationship (B-R) diagram or a Semantic Data Model (SDM) 
application. 

In most representation mechanisms, the users 
describe their information needs in terms of entities, 
attributes, and relationships {E-E diagrams) , or in terms of 
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records, items, and sets using a DBMS’s data description 
language (DDL). It is clear that a great deal of gererality 
and potential design optimality are lost when the user is 
restricted to a particular low-level data description 
language instead of a higher-level representation mechanism 
to specify their information requirements. Similarly, the 
goal of the Semantic Data Model (SDM) is as follows: 

"Our goal is the design of a higher- level database model 
that will enable the database designer to naturally and 
directly incorporate more of the semantics of a database 
into its schema. Such a semantics-based database 
description and structuring formalism is intended to 
serve as a natural application modeling mechanism to 
capture and express the structure of the application 
environment in the structure of the database." 
[Hef. 10:p. 352] 

Ihere are two major reasons for a designer to use a 
high level of abstraction in the design process. First, 
entities, attributes, and relationships are not always 
explicitly distinguished and the design decisions are often 
fuzzy. Second, the problem of consistency checking would be 



simplified 


if a common, high-level 


information 


representa- 


tion for 


conceptual information 


structures 


could 


be 


developed. 

As 


an example, conceptual 


design can 


be done 


by 



entity modeling which is the representation and integration 
of user views in terms of entity diagrams. There are four 
basic design decisions required to formulate the entity 
diagrams. 

1 . Selection of entities 

2. Selection of ertity attributes 

3. Selection of key attributes for entities 

4. Selection of relationships between entities. 

3 . I mpleme n tati on Desig n 



to use 



The major goal of the implementation design step is 
the results cf the conceptual design step and the 



processing requirements as input to create a 
DBMS-processible schema as output. Eefinements to the data- 
base structure that occur during this design step are devel- 
oped from the vie\jpoint of satisfying DBMS-dependent 
constraints as well as constraints specified in the user 
requirements. 

Inplementaticn design contains database structure 
design and design of programs. The database structure is a 
DBMS-processible data definition or schema, usually 
expressed in a data definition language. If there are phys- 
ical parameters to be selected in a data definition 
language, selection of appropriate characteristics are 
deferred until the physical step. The program design is 
related to the development of structured programs using the 
host language and data manipulation language of the DBMS. 
Conceptual design and implementation design steps are 
together referred to as logical design by some authors. 



4 . P hysic al D esign 

Physical database design is . the process of devel- 
oping an efficient, implementable physical database struc- 
ture from a given logical database structure that has been 
shown to satisfy user information requirements. 

Physical database structure represents stored record 
format, access method, and device allocations for a 
mult iple-record- type database. 

Major decision classes of physical design are : 

1. Stored record format design. This contains all forms 
of data representation and compression in stored 
records. It also contains record partitioning. Record 
partitioning defines an allocation of individual data 
items to separate physical devices of the same or 
different type, or separate extents on the same 
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device, so that the total cost of accessing data for 
a given set of user applications is minimized. 

2. Access method design. An access method provides 
storage and retreival capabilities for data stored 
on physical devices, usually secondary storage. 
Storage structure and search mechanisms are two 
important components of an access method. Storage 
structure defines the limits of possible access paths 
through indexes and stored records, and the search 
mechanisms define which paths are to be selected for 
given applications. A given file may have many asso- 
ciated access paths. Physical databases may require 
several primary access paths. Efficiency considera- 
tion of the dominant application describes the 
design of individual files. Access time can be 
greatly reduced through secondary indexes, but at the 
expense of increased storage space overhead and index 
maintenance. 

3. Stored record clustering. The physical allocation of 
stored records to physical extents is one of the most 
important design decisions. Record clustering 
involves the allocation of records of different types 
into physical clusters to take advantage of physical 
sequentiality whenever possible. Analysis of record 
clustering must take access path configurations into 
account to avoid access-time degradation due to a new 
placement of records. Clustering also involves block- 
size selection for efficient retreival. Blocks in a 
given clustered extent are influenced by stored 
record-size and storage characteristics of the phys- 
ical devices. 
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17. DATABASE MODELS 



A. INTECDDCTION 

A data model is a representation of data and their rela- 
tionships which describes ideas about the real world. Data 
models have been used to represent a conceptual view and an 
implementation view of data. Therefore, we will classify 
the data models as fellows: 

1. Ccnceptual data models 
Semantic Data Model (SDM) 

Entity-Relationship (E-R) model 

2. Implementation data models 
Relational data model 
Hierarchical data model 
Network data model 

One of the major responsibilities of the database admin- 
istrator is to develop a conceptual model of the organiza- 
tion. The conceptual model is a communications tool between 
the various users of data, and it is developed without any 
concern for physical representation. 

The conceptual model should be independent of a database 
management system. The conceptual model has to be mapped to 
the implementation model used as the underlying structure 
for a DBMS. The commercial DBMSs available today are based 
either on a relational data model, hierarchical data model, 
a network data model, or a combination of them. It is 
important to understand that the DBMS is not a factor in 
designing a conceptual model, but designing an implementa- 
tion model is dependent on the DBMS to be used. 

In reality, the lEHS is frequently given, and the data- 
base administrator has no choice. The reason for this 
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situation is that a particular computer may support only one 
or two DBAS'. On contrast, the choice of the DBAS should be 
made after the conceptual model is designed. The process of 
mapping from the ccnceptual model to the implementation 
model should be examined while evaluating different DBMS 
packages. At that time, the DBMS should be a dominant factor 
when selecting the computer, 

E. CCHCEPTDAL DATA MODELS 

1 , S emantic Data Model (SDH) 

Contemporary DBMSs are based on database models 
which have limited capabilities for expressing the meaning 
of a database. These database models do not adequately 
relate a database to its corresponding application environ- 
ment. Therefore, a database model is needed which allows us 
to capture much more of the meaning of a database. The 
semantic database model is a higher-level database model and 
it is designed to provide features for the natural modeling 
of database application environments. The semantic data 
model provides a precise documentation and communication 
medium for database users. More details of the semantic data 
model will be given in Chapter V. 

2. The Ent itv-R e lation s hip (E-R) Mode l 

The entity-relationship model is a conceptual data 
model and is based on the view that the real world consists 
of entities and relationships between entities. In this 
model, real world objects and their characteristics are 
represented by entities and their attributes. 

An entity is a "thing” which may be distinctly iden- 
tified; examples are records of officers, units, and so 
forth. Individual entities are classified into entity sets- 
that is, collections of entities that may be described by 
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the same set of properties. Entities with the same attri- 
butes fall into one entity set. All OFFICER records form the 
officer entity set; all DNIT records form the unit entity 
set. A relationship set is an association between two or 
more entity sets. The relationship has its own data (e.g., 
date of assignment, order number of assignment). 

Entities and relationships can be represented 
dia grammatically by an entity-relationship (E-E) diagram. 
Each entity set is represented by a rectangular box, and 
each relationship set by a diamond-shaped box in this 
diagram. The diamond-shaped boxes (relationship sets) are 
joined to the rectangular boxes (entity sets of entities 
which participate in the relationship). Figure 4.1 presents 
a diagram that shows the relationship of the officer and 
unit ertity sets. 




Figure 4.1 E-R Diagram for OFFICER/ONIT Relationship. 
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OFFICER OFFICER OTHER 

MID NAME DATA 



10000 

11009 


SMITH 1 

DA7IS 




20112 

31052 

35278 


OZIN 

BDIUKONER 

SARI 




38935 


OZKAN 





a, OFFICER Data 



UNIT 


UNIT 


OTHER 


ID 


NAME 


DATA 


57BRI 


57th BRI 




85DIV 


85th DIV 




07REG 


7th REG 




35BT 


35th BT 




03CC 


3rd CO 





b. UNIT Data 



OFFICER 


ONIT 


DATE OF 


ASSIGNMENT 


MID 


ID 


ASSIGNMENT 


ORDER NO 


1 1009 


57BRI 


781104 


104578-9 


10000 


3 SET 


790109 


125779-1 


31052 


03CO 


790112 


363479-6 


31052 


3 5BT 


801220 


563480-7 


20112 


03CO 


810211 


258281-6 


10000 


85DI7 


830818 


745683-3 


32578 


3 5ET 


840830 


563484-1 



c. Relationship Data 



Figure 4.2 Three Tables of Data for the E-R Diagraa. 
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IHPLEMEBTATION Dill HODEIS 



Implementation data models are chosen to provide 
constructs that can model a variety of user problems. Most 
commercial database management systems support a single data 
model. It is common to classify these models into three 
classes : 

.Ihe relational model 
.The hierarchical model 
.The network model 



. The main difference between the 
models lies in the representation 
between the entities. 



three classes of data 
of the relationships 



1 



The Relational Data Model 



In a relational data model, the entities and their 
relationships are represented with two-dimensional tables. 
Every table represents a relation and is made up of rows and 
columns. Rows of such tables are generally referred to as 
tuples. Likewise, columns are usually referred to as attri- 
butes. Pigure 4.3 shows three relations, one for officers, 
one for units, and tbe other for assignments. 
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OFFICER 

HID 


OFFICER 

NAME 


OTHER 

ATTRIBDTES 


10000 


SMITH 




11009 


DA7IS 




20112 


0 ZIN 




31052 


BOYUKONER 




35278 


SARI 




38935 


02KAN 





a. OFFICER Relation 



UNIT 


UNIT 


OTHER 


ID 


NAME 


ATTRIBDTES 


57BRI 


57th BRI 




85DI7 


85th DIV 




07REG 


7th REG 




35BT 


35th BT 




03CO 


3rd CO 





b. UNIT Relation 



OFFICER 


DNIT 


DATE OF 


ASSIGNMENT 


MID 


ID 


ASSIGNMENT 


ORDER NO 


11009 


57BRI 


781104 1 


104578-9 


10000 


3 5BT 


790109 


125779-1 


31052 


0 3CO 


790112 


363479-6 


31052 


3 SET 


801220 


563480-7 


20112 


0 3CO 


810211 


258281-6 


10000 


8 5DI7 


830818 


745683-3 


32578 


35ET 


840830 


563484-1 



c. ASSIGNMENT Relation 



Figure 4,3 Sample Data in Relational Fora 



The relational data model approach is a high-level 
data retrieval and manipulation tool that separates the user 
from the complexity of storage structures, data structures, 
and access paths. Access paths do not have to be predefined. 
The lack of predefined physical access paths means that 
relational databases must be exhaustively searched to 
satisfy a guerry. The advantages of a relational data model 
is its simplicity and its well-developed theoretical 
foundation. 

There are several commercially available DBMS pack- 
ages based on the relational model. Some of them are: IBM's 
SQL/DS, and System E, Relational Software Inc.'s ORACLE, 
Relational Technology Inc.'s INGRES, Britton-Lee Inc.'s 
IDM500, Honeywell's MRDS/LINUS, Ashton-Tat e' s dbase II, and 
National Computer Sharing Services' NOMAD. The relational 
data model will be discussed in greater detail in Chapter 
VI. 



2 • Hierarchical E^a M ode l 

The hierarchical data model is made up of a hier- 
archy of the entity types involving a dominant (root) entity 
type and one or more subordinate (dependent) entity types at 
the lower levels. The relationship between a dominant and a 
subordinate entity type is one-to-many. That is, for a given 
dominant entity there may be many subordinate entity types, 
and for a given dominant entity occurrence, there can be 
many occurrences of a subordinate entity type. 

The relative simplicity and ease of use the hier- 
archical data model and the familiarity of data processing 
users with a hierarchy are major advantages of a hierarch- 
ical data model. Disadvantages of a hierarchical data model 
are : 

.The operations of insertion , and deletion are complex, 
.Any subordinate node is accessible only through its 
dominant node. 
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Some examples of commercially available DBMS pack- 
ages based on hierarchical data model are IBM's IMS, Intel’s 
■ SYSIBM 2000, and Informatics MARK IV. 

3 - Net wor k Data Model 

The concept of the network data model is based on 
the work of the COEASIl DBTG (Conference On Data Systems 
languages Database Task Group) . The network data model 
employs the set construct. The term set has a different 
meaning than its mathematical sense. 

The network model of a system is diagrammatically 
represented by a data structure diagram, which was intro- 
duced by C.N. Bachman. In this diagram a rectangle enclcsing 
a name denotes an entity or record type. Each record type is 
composed of data items; but the particular item names are 
not shown in this description, although they are defined in 
the complete database description by the data definition 
language. In a data structure diagram, a directed arrow 
connects two record types. The record type located at the 
tail cf the arrow is called the owner-record type, and the 
record type located at the head is called the member- record 
type. The arrow directed from owner to member is called a 
set type and it is given a name. Thus the data structure 
diagram in Figure 4,4 represents the set type ASSIGNED- TO. 
Here DNIT is the owner record type, and OFFICER is the 
member record type. 

The existence of a set type specifies that there are 
associations between records of heterogeneous types in the 
database. This allows the designer to interrelate diverse 
record types and thus to model associations between diverse 
entities in the real world. 

There is a distinction between a set type and a set 
occurrence as well as between record type and record occur- 
rence. For example, SMITH and DAVIS denote two record occur- 
rences within the record type OFFICER. 



UNIT 



ASSIGNED_TO 

V 



OFFICER 



Figure 4.4 A Network Structure. 

Ike existence of a set type is declared by naming 
it, stating its owner-record type (only one) and its member- 
record type, A set occurrence is one occurrence of the 
owner-record type together with zero or more occurrences of 
each member-record type. This means that there is an occur- 
rence of a set type whenever there is an occurrence of its 
owner-record type. A set occurrence is an one-to-many rela- 
tionship that is the basic building block for relating 
diverse records. The following associations exist among the 
owner and member records of any set occurrence; 

.Given an owner record, it is possible to process the 
related member records of that set occurrence, 

.Given a member record, it is possible to process the 
related owner reccrd of that set occurrence. 

.Given a member record, it is possible to process ether 
member records in the same set occurrence. 

Any implementation that conforms to these three 
rules is a valid implementation of the concept of a set 
type. Two occurrences of the ASSIGNED-TO set type are shewn 
in Figure 4.5 
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Figtire 4.5 Occurences of Set Type ASSIGNED-TO. 

A set occurrence with no member-record occurrences 
is called an "empty set." A given member record may exist in 
only one set occurrence of a given type. A member record 
cannot simultaneously belong to two owner records for the 
same set type. 

It is also possible to implement hierarchies (one- 
to-many relationships) and many-to-many relationships with 
set structures in the network data model. 

The major advantage of the network model is that 
there are successful database management systems that use 
the network data model as the basic structure. The main 
disadvantage of the network model is its complexity. 

There are several commercially available database 
management system packages based on this model. Some of them 
are: Burroughs’ DUS II, CDC’s DMS-170, Cullinane’s IDMS, 
Cincom’s TOTAL, Honeywell's IDS/II, Univac's DMS1100, 
Digital Equipment Corporation’s DBMS-10/20. 
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7. S EHAMTIC DATA MOD EL (SDM) 



A. IBTBODDCTION 

The semantic database model (SDM) was introduced by 
Hammer and McLeod [Bef. 10:pp. 351-376], and can serve as a 
conceptual database model in the database design process. 
The semantic database model allows the same information to 
be viewed in several ways. 

Each database is a model of some real world environment. 
The contents of a database are intended to reflect a snap- 
shot of the state of this real world environment, and every 
change to the database should reflect an event occuring in 
that environment. Therefore, a logical database represents 
selected portions of reality. Eventually, we may ask gues- 
tions like: How do we represent the real world environment? 
T?hat are the structures of the real world environment? Also, 
we may ask the questions about the other aspect of the 
problem, such as: How do we represent the conceptual world? 
What are the structures of the conceptual world? 

1 . St r uctu r es of B eal World Envir o nment 

Ihe first structure is the obje ct . The real world 
has objects; they are phenomena that can be represented by 
nouns. An officer, a unit, an assignment_reguest are all 
objects. Objects are grouped into object classe s by 
performing generalization. Objects are grouped together on 
the basis of similarities. CFFICEB is an example of an 
object class. 

Objects have p ropertie s. A property is a character- 
istic of an object. For example, an officer's name and rank 
are properties. Properties are inherent in objects. The 
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collection of all possible values of a property is called a 
prop er ty value set . Ihe property value set for officer rank 
is the collection of all ranks for all possible officer 
ob j ects. 

A fact is an assertion that, for a given object, a 
particular property has a particular item from the property 
value set. The statement that the rank of DAVIS is ’captain’ 
is a fact. A fact is the intersection of a given object with 
a given property value set. 

Objects can he related to one another. These rela- 
tions are called associations . Associations may exist 
between objects of the same class or of different classes. 
The association ’commander’ exists between objects of the 
same class (OFFICER). The association ’assignment’ exists 
between two different classes (between OFFICER and UNIT 
object classes.) Also, an object may have an association to 
itself. Associations may have properties just as objects 
have properties. The ’assignment’ association may have a 
property such as Date_of_assignment. 

A summary of real world structures is shown in 
Figure 5.1. 



2 . Str uctures of Conce£tu al World 

Database designers should define a conceptual struc- 
ture for each of the real world structures. 

An entity is a conceptual representation of an 
object. Entities may be grouped into ent ity classes . An 
entity class is a representation of an object class. An 
entity class consists of all the entities that represent the 
objects of an object class. If there is an object class 
called OFFICER, then there can be an entity class called 
OFFICER. 
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Structure 


Definition and Examples 


Object 


Phenomena that can be represented by 
nouns. An officer, a unit. 


Object Classes 


A group of objects formed by general- 
ization. OFFICER, UNIT. 


Properties 


Characteristics of objects. Name, 
Rank. 


Property value 
set 


The collection of all possible 
values of a given property. 

All ranks for Officers. 


Fact 


The intersection of a given object 
with a given property value set. 
Rank of officer DAVIS is captain. 


Association 


A connection of objects of the same 
or different classes. 

EAVIS is assigned to unit ALPHA. 

j 



Figure 5. 1 Structures in the Real World. 

Entities have attrib utes that are representations of 
properties of objects. Attributes describe and characterize 
entities. RanX ,Name,Date_of_assignnient are examples of 
attrilutes. 

Ihe conceptual structure that represents property 
value sets is called a domai n. A domain is the collection 
of all values that an attribute can have. The domain of 
Names is a collection of character strings of some appro- 
priate length. The domain of height (in centimeters) is the 
integers from 0 to 250. 

A v alu e is the representation of a fact. The value 
is the intersection of a given entity with a given domain. A 
relatio nshi p is the conceptual representation of an associa- 
tion. Relationships may exist among entities in the same 
class or in different classes. An entity may have a rela- 
tionship to itself. A relationship may have attributes, just 
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as associations may have properties. The assignment relation 
may have a property such as Date_of _assignment. 

Associations between real wcrld structures and 
conceptual structures are shown in Figure 5,2 



Real World Structure 


Conceptual Structure 




Object 


Entity 




Object Class 


Entity Class 




Property 


Attribute 




Property value set 


Domain 




Fact 


Value 




Association 


Relationship 


J 



Figure 5, 2 Real World and Conceptual Structures- 



B. CINEBAl PRINCIPIIS OF DESIGNING SDM 



As described in [Ref. 10:p. 355], there are general 

principles of database organization to support the design of 
SDH. These are: 



" (1)~ A database is to be viewed as a collection of 
entities that correspond to the actual objects in the 
application environment. 

(2) - The entities in a database are organized into 
classes that are meaningful collections of entities. 

(3) - The classes of a database are not in general 
independent, but rather are logically related by means 
of interclass connections. 

(4) - Database entities and classes have attributes 
that describe their characteristics and relate them to 
other database entities. An attribute value may be 
derived from other values in the database. 
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(5)- There are several primitive ways of defining 
interclass connections and derived attributes, corre- 
sponding to the most common types of information redun- 
dancy appearing in database applications. These 
facilities integrate multiple ways of viewing the same 
basic information, and provide building blocks for 
describing complex attributes and interclass 
relationships, " 



C. DEJIBIBG ENTITY CLASSES 

The basic format of an SDH entity class description is 
shown in Figure 5,3 £Bef. 6;p. 213], 



ENTITY_CLASS_NAME 
[description: - 



] 



[interclass connection: 



] 



member attributes: 

Attribut 6_name 

[description: ] 

value class: 

■ mandatory ] 

■ multi valuedj[ no overlap in values] 
‘exhausts value class] 

‘not changeable] 

‘inverse: Attribute_name] 

‘match: Attribute namel of ENTITY_CLASS 
on A ttriEute_name2 ] 
[derivation: ] 



[class attributes: 



Attribute name 

[description: ] 

value class: 

[derivation: ] ] 



[ identifiers; 

Attribut e^namel + [ A ttribute_name2+[ •••]]] 



Figure 5,3 Format of SDH Entity Class Descriptions, 
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An SDH database is a collection of entities. Entities are 
organized into classes. The structure and organization of an 
SDM database is specified by an SDH schema. SDH schema 
identifies the classes in the database. Appendix A is an 
example cf an SDH schema for 'Personnel Database.' 

Each entity class in an SDH schema has the following 
features : 

1 . A cl ass name identifies the class. Each class name 
must be unique with respect to all class names used 
in a schema. OFFICER, ONIT, ASSIGNHENT_REQDEST are 
all class names. 

2. The class has a collection of members (the entities) . 
Each class in an SDH schema is a homogeneous collec- 
tion of one type of entity. 

3. A textual class description is an optional feature of 
entity class. It describes the meaning and contents 
of the class. 

4. The class has several attributes which describe the 

members of that class or the class as a whole. There 
are two types cf attributes: M embe r attr i but es and 

Cla ss attributes . For example, each member of class 

UNIT has attributes Name, Dnit_category , Location 
which identify the unit's name, its category, and its 
location, respectively. A class attribute describes a 
property of a class taken as a whole. For example, 
the class A£SIGNHENT_REQOEST has the attribute 
Number_of_reguests, which identifies the number of 
requests issued in the current year. 

5. An SDH class can either be base or nonbase. A base 
class is one that is defined independently of all 
other classes in the database. In Appendix_A the 
class OFFICER is a base class. It exists indepen- 
dently of other classes. If we think of an entity 
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class such as COMHaNDERS, it is a subset of the 
OFFICER class, and so can te derived from this class. 
The class, COMMANDERS is called as an nonbase class, 
and it does not have independent existance. Every 
ncnbase class has an entry, interclass connection, 
that describes how the class is to be constructed. 

6. If the class is a base class, it has identif iers . 
These are attributes that uniciuely identify members. 
For example, class OFFICER has the unique identifier, 
Military^ID- 

D. DEFINING ATTRIBOIIS 

There is a collection of attributes in each class 
description. These attributes represent the properties of 
objects. Each attribute has the following features. 

1. An at tribute n ame identifies the attribute. Attribute 
names must be unique within the class where they are 
defined. They must be unique within all classes that 
are derived from their class of definition. 
Date_of_promoticn, Main_branch are examples of attri- 
bute names. 

2. The attribute has a value which is either an entity 

in the database (a member of some class) or a collec- 
tion of such entities. The value of an attribute is 
selected from its underlying value class. Va lue 

class is another term for domain that contains the 
permissible values of the attribute. The value class 
of an attribute may be any class in the schema or may 
be the special value NUIl. (i.e., no value.) DATE, 
BRANCHES are examples of value classes. 

3. The applica bility of the attribute is specified by 
indicating that the attribute is either: 
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(a) a member attribute, which applies to each member 
of the class, and so has a value for each member 
(e.g., Hilitary_ID of OFFICER), or 

(b) A class attribute, which applies to a class as a 
whole, and has only one value for the class (e.g., 
Numter_of_reguests of ASSIGNI1ENT_REQDEST. ) 

4. A textual attribut e description is an optional 
feature that describes tha meaning and purpose of the 
attribute. This serves as an integrated form of 
database documentation. 

5. The attribute is specified as either sin g le valued or 

mul ti valued . A single-valued attribute has one 
value, that is, a member of the value class of the 
attribute. The value of a multivalued attribute is a 
subclass of the value class (e.g., 

Foreign_language_capability of OFFICER is a multiva- 
lued attribute.) The default value for this feature 
is single valued. 

6. An attribute can be specified as mandator y , which 
means that a null value is not allowed for it. For 
example, attribute Military_ID of OFFICER is speci- 
fied as "mandatory"; this models the fact that every 
OFFICER has a Military_ID. 

7. An attribute can be specified as not ch ang eable . 
which means that once set to a nonnull value, this 
value cannot be altered except to correct an error. 
For example, attribute Military_ID of OFFICER is 
specified as "rot changeable." 

8. A member attribute can be required to be exhaustive 
of its value class. This means that every member of 
the value class of the attribute is used. 

9. Finally, multivalued attributes can be specified as 

nop o ver lappin g. This means that a member of the 

value class can be used at most once. 
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E. BEHBEB ATTEIBOTE IMTEBBELATIONSHIPS 



The semantic data model provides three facilities for 
defining interrelationships among member attributes. These 
facilities are inversion, matching, and derivation. 

1 . Inversion 

The inverse facility causes two entities to be 
contained within each other. Member attribute A1 of class Cl 
can be specified as the invers e of member attribute A2 cf C2 
which means that the value of A1 for a member Ml of Cl 
consists of those members of C2 whose value of A2 is Ml. 

Inverses are always specified by a pair of attri- 
butes which establishes a binary association between the 
members cf the classes- For example, in Appendix_A the 
entity classes OFFICER and UNIT are inverses of each other. 
In OFFICER, the attribute Unit_assigned has the value class 
UNIT, and the inverse attribute Off icer_assigned. In UNIT, 
the attribute Off icer_assigned has the value class OFFICER, 
and the inverse attribute Unit_assigned. 

2 . Matching 

The second SEM facility for representing relation- 
ships is mat ching . fiith matching, a member of one entity 
class is matched with a member of another entity class. The 
value of the match attribute A1 for the member Ml of class 
Cl is determined as fellows. 

1. A member M2 of some class C2 is found that has Ml as 
its value of aember attribute A2. 

2. The value of member attribute A3 for M2 is used as 
the value of A1 for Ml. 

For a multivalued attribute (call it A1) , it is 
permissible for each member of Cl to match to several 
members of C2; in this case, the collection of A3 values is 
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the value of attribute A1. In other words, the value cf an 
attribute in one of the members is moved to the other. 

Inversion and matching provide multiple ways of 
viewing n-ary associations among entities. Matching supports 
binary and higher degree associations, while inversion 
allows the specification of binary associations. 

lor example, a matching specification in Appendix A 
indicates that the value of the attribute 
Foreign_language_capability of a member 0 of class OFFICER 
is equal to the value of attribute Foreign_language of the 
member F of class FOREIGN_LANGOAGE whose FID value is 0. 

3 . D erivation 

SDM provides the ability to define an attribute 
whose value is calculated from other information in the 
database. Such an attribute is named de rived . 

The approach is to provide a small vocabulary of 
high-level attribute derivation primitives that directly 
model the most common types of derived information. Each of 
these primitives provides a way of specifying one method of 
computing a derived attribute. 

F. CIASS ATTEIBOTE IBTEEBELATIOHSHIPS 

Attribute derivation primitives for member attributes 
can be used to define derived class attributes, as these 
primitives derive attribute values from those cf ether 
attributes. Of course, instead of deriving the value of a 
member attribute from the value of other member attributes, 
the class attribute primitives will derive the value of a 
class attribute from the value of other class attributes. 
Moreover, there are two other primitives that can be used in 
the definition of derived class attributes: 
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. An attribute can be defined so that its value equals 
the number of members in the class it modifies. For 
example, attribute Number__of _requests is derived from 
A£SIGNHENT_REQDEST record by summation of members as 
specified. 

2. An attribute can be defined whose value is a function 
of a numeric member attribute of a class; the func- 
tions available are "maximum”, "minimum", "average", 
and "sum” taken over a member attribute. The ccmpu- 
tation of the function is made over the members of 
the class. 
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VI. BEIATIONAL DATABASE MODEL 

A. EiLAIIOHAL DATA STBOCTOEE 

In order to explain the relational data structure, it 
will he very helpful to use the sample data in relational 
form. Figure 6.1 reflects a relational view of the data 
which is organized into three tables: OFFICEE (officers who 

are in the army) , CCDESES (all courses which are offered) , 
and CCDBSE_ATTENCED (officers who took some courses) . The 
OFFICEE table contains, for each officer, a military identi- 
fication number, rank, name, and the city where the officer 
was born; the COUESES table contains, for each course, a 
course code, course name, brief description of that course, 
duration, and location where the course is offered; and the 
COOR SE_ATTENDED table contains, for each grade, a military 
identification number, a course code, and a grade taken. The 
following assumptions regarding officers, courses, and 
course attended are made. Each officer has a unigue military 
ID number, exactly cne rank, name, and city name. Each 
course has a unigue course code, exactly one course name, 
description of the course, duration, and location. At any 
given time, no more than one grade exists for a given 
officer/course combination. 

1 . Definition of a R elatio n 

Assume that we are given a collection of sets El , 
E2, ... ,En (they are not necessarily distinct) , R is a 

relation on those n sets if it is a set of ordered n-tuples 
<e1, 62, ... , en> such that el belongs to El, e2 belongs to 
E2, ... , en belongs to En. Sets El, E2, ... , En are the 

d oma ins of E. The value n is the degre e of R. It is 
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Figure 6.1 Saaple Data in Relational Fora. 

sometimes called aritv n [Bef. 3:pp. 83-93], [Ref. 9:pp. 

14-25 1. 

From the mathematical set-theory perspective, we can 
give another equivalent definition of a relation that is 
sometimes useful. A relation is any subset of the Cartesian 
product of one or more domains. For example, if we have n 
sets, say n=2, E1={a,h), and E2={0,1,2}, then El x E2 is the 
Cartesian product of these n sets. That is, it is the set of 
all possible ordered n-tuples <e1,e2> such that el belongs 
to El, e2 belongs to E2. The result of this Cartesian 
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product of El X E2 is { (a,0) , (a, 1) , (a,2) , (b,0) , (b, 1) , (b,2)} . 
Figure 6.2 , for example, shows the Cartesian product of two 
sets HID and CCODE (Military ID No. , and Course Code) . 




Figure 6.2 Am Example of a Cartesian Product. 

A relation called CODESES, of degree 5 is illus- 
trated in Figure 6.1 (b) . The five domains are sets of 
values representing, respectively, coarse codes (CCCDZ) , 
course titles (TITIE) , brief description of each course 
(CDESCRIPT) , duration for each course, and locations where 
courses are offered. The "course title" domain, for example, 
is the set of all valid course titles; note that there may 
be some titles included in this domain that do not actually 
appear in the COURSES relation at this particular moment. 

It is convenient to view a relation as a table, 
where each row is a tuple and each column corresponds to one 
component. The columns are often given names, called attri- 
butes. The number cf tuples in a relation is called the 
cardinality of that relation; e.g. , the cardinality of the 
COURSES relation is four, and it has five attributes (or 
columns). As mentioned earlier, a domain can be thought as a 
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pool cf values from which the actual values for a given 
attribute are drawn. It is very important to note that the 
domains of a relation do have an ordering defined among 
them. If we have a tuple (a1,a2, ... /Un) with n components, 
the value of the j th component in this n-tuple has to be 
drawn from the j th dcmain. In Figure 6.1 (b) , (C2, Cobol, 
Cobol Prog. Language, 8, Monterey) is the second tuple of 
the CCDESES relation, and the value of the fourth ccmpcnent 
of this tuple under the attribute named DURATION is drawn 
from the fourth domain which is a- set of positive integers, 
ranging from 0 to 9SS. Mathematically speaking, the rear- 
rangement of the five columns of the COURSES relation into 
some different order results a different relation. 

It is important to note the difference between a 
domain and attributes which are drawn from that domain. An 
attribute represents the use of a domain within a relation. 
Figure 6.3 shows a part of a relational schema in which four 
domains (MILITARY_ID, HILITART_RANK, OFFICER_N AHE , and 
lOCAIICN) and one relation (OFFICER) have been defined by 
using a data definition language [Ref. 3:pp. 83-93]. ' The 
relation is declared with four attributes (MID, RANK, NAME, 
and CITY), and each attribute is specified as being drawn 
from a corresponding domain. It is sometimes possible that 
the domains of more than one attribute can be the same. In 
other words, those attributes can use the same domain in 
common. To differentiate between attributes that have the 
same domain, each is given a unigue attribute name. A 
crucial feature of relational data structure is that associ- 
ations between tuples are represented solely by data values 
in attributes (columns) drawn from a common domain. 

All relations in a relational database are reguired 
to satisfy the following condition. 

"Every value in the relation (i.e. , each attribute value 
in each tuple) is atomic (i.e.. nondecom posable so far 
as the system is concerned)." [Ref. 3:p. 86] 
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That is, at every row-and-column position in the tahle there 
always exists precisely one value, never a set of values. 
But in the case of having "unknown” or "inapplicable" 
values, null values can be allowed to represent these 
special values in a relation. This is the idea of normaliza- 
tion. If a relation satisfies the above condition, it is 
said to be normalized. This idea will be discussed in detail 
later. 
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CHAEACTEE (15) 

: DOMAIN MI1ITAEY_ID, 

: DOMAIN MILITAEY_EANK, 
: DOMAIN OFFICEE_NAME, 

: DOMAIN LOCATION) 



Figure 6.3 Domains and Attributes. 

The generalized format or notation which is used to 
represent a relation is called the relation structure. For 
example, OFFICEE (Mid, Eank, Name, City) is the structure of 
the OFFICEE relation. In general, Eelation_name (attri-. 
butel, attribute2, ... ,attributeN) is the general format to 
show the structure of a relation. If we add constraints on 
allowable data values to the relation structure, we then 
have a relational schema [Eef. 11]. 
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2 . Keys 

It is frequently the case that within a given rela- 
tion there is one attribute with values that are unique 
within the relation and thus can be used to identify the 
tuples of that relation. Attribute HID of the OFFICER rela- 
tion, for example, has this property. Each OFFICER tuple 
contains a distinct MID value, and this value may be used to 
distinguish that tuple from all others in the relation. MID 
is called the p rima ry key for OFFICER. 

A single attribute may not always be the primary key 
in' a relation. However, the values of more than one attri- 
bute together may constitute a unique identifier. Thus, seme 
combination of attributes, when taken together, have the 
unique identification property. In the relation 
COORSE_ATTENDED (Fig. 6.1 ), for example, the combination 
(MID, CCODE) has this property. The existence of such a 
combination is guaranteed by the fact that a relation is a 
set. Since sets do not contain duplicate elements, each 
tuple of a given relation is unique with respect to that 
relation, and hence at least the combination of all attri- 
butes has the unique identification property. In the above 
example, the combination (HID, CCODE) is said to be a 
comp osite key as well as a primary key for the OFFICER 
relation. 

On the other hand, occasionally we may encounter a 
relation in which there is more than one attribute combina- 
tion having the unique identification property and hence 
more than one can d idate key. In such a case we may arbi- 
trarily choose one of the candidates as the primary key for 
the relation. If a candidate key is not the primary key, it 
is called an alterna te key [Ref. 3:pp. 83-93]. The COURSES 

relation in Fig. 6.1 (b) is such a relation. Each course 

has a unique course code and a unique course name (TITLE) . 



70 



If the designer chooses one of these candidate keys, say 
CCODE, as the primary key for the relation, TITLE will te an 
alternate key. 

The primary key is a unique identifier for tuples in 
a relation. Those tuples represent entities in the real 
world, and the primary key really serves as a unigue identi- 
fier fcr those entities. For example, the tuples in the 
OFFICER relation represent individual officers, and values 
of the HID attribute actually identify those officers, not 
just the tuples that represent them. As a result of this 
interpretation, we can now introduce the following rules 

’’.Integrity Rule 1 (Entity integrity) 

No component of a primary key value may be null." 

[Ref. 3:p. 89] 

. According to the definition, all entities must have 
a unigue identification of some kind. That is, they must be 
distinguishable from each other. Primary keys perform the 
unigue identification function in a relational database. If 
a primary key value is null in a relation, this implies that 
there is some entity that does not have a unigue identifica- 
tion. In other words, it is not distinguishable from ether 
entities. It is strongly recommended that both wholly and 
partially null identifiers be prohibited. 

Those types of arguments lead us to a second integ- 
rity rule. Occasionally one relation includes references to 
another. Relation CODRSE_ATTEHDED, for example, includes 
references to both the OFFICER relation and the COURSES 
relation, via its HID and CCCDE attributes. It is clearly 
seen that if an occurrence or a tuple of COURSE_ATTENDED 
contains a value for MID, say ID2, then a tuple for officer 
ID2 should exist in OFFICER. Otherwise, the COURSE_ATTENDED 
tuple would refer to an nonexistent officer; and similarly 
for courses. To make these notions clear, we should under- 
stand the notion of pr imary doma in. 



"A given domain may optionally be designated as primary 
if and only if there exists some single-attribute 
primary key defined on that domain.” [Eef. 3;p. 89] 

For example, we may designate the domain MILITARY_ID as 
primary, by extending its definition shown in Fig. 6.3 as 
follows ; 



DOMAIN niLITAEY_ID CHAEACTEfi (9) PRIMARY 



Any relation which contains an attribute that is 
defined on a primary domain (for example, relation 
COOESE_AITENDED) must obey the following rule. 



’’.Integrity Rule 2 (Referential integrity) 

Let D be a primary domain, and let R1 be a relation with 
an attribute A that is defined on D. Then, at any given 
time, each value of A in R1 must be either (a) null, or 
(b) equal to V, say, where V is the primary key value of 
some tuple in some relation R2 (Rl and R2 not neces- 
sarily distinct) with primary key defined on D. ” 
[Ref. 3:p. 89] 



Here, relation R2 must exist because of the defini- 
tion cf primary domain, and if attribute A is the primary 
key of El, the rule is trivially satisfied. When an attri- 
bute such as A in one relation is a key of another relation, 
the attribute is called a fore ign key. For example, attri- 
bute CCODE of relation COURSE^ATTENDED is a foreign key, 
because its values are values of the primary key of the 
COURSES relation. 



3. Extentions a nd Intentions 

An extention and an intention are actually compo- 
nents of a relation in a relational database. 

The set of tuples existing in a given relation at 
any given instant is known as the extention of that rela- 
tion. Thus the extention changes with time. That is, it 

varies depending upon the several operations performed on 
tuples which are added, deleted, and updated. 
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Ihe intention of a given relation is the permanent 
part of the relation. It is independent of time. The inten- 
tion corresponds to what is declared in the relational 
schema. Hence, the intention is the combination of the rela- 
tion structure (sonetimes called the naming structure) 
mentioned earlier and the integrity constraints which can be 
subdivided into key constraints, referential constraints, 
and other constraints. Key constraints are constraints 
implied by the existence of candidate keys. The primary key 
specification and the alternate keys specifications included 
by* the intension imply a uniqueness constraint (by the defi- 
nition of candidate key) and a no-nulls constraint (by 
Integrity Eule 1) respectively. Referential constraints are 
constraints implied by the existence of foreign keys. A 
specification of all foreign keys in the relation implies a 
referential constraint (by Integrity Rule 2) . The relations 
in Figure 6.1 are examples of extentions and they also show 
the intentional relation (or naming) structure which 
consists of the relation name plus the names of the attri- 
butes. The operational data appearing under those attributes 
are the extention part of those tables. 

B. REIATIONAL ALGEBBA 

Relational algebra is a collection of operations on 
relations. Each operation takes one or more relations as its 
operand (s) and produces another relation as its result. A : = 
E + C;, for example, is an arithmetic expression in PASCAL 
Programming Language. B and C are operands known as vari- 
ables fox the addition operator (+) . After performing this 
operation, the result will be assigned into the variable A. 
Likewise we encounter B and C as two relations and plus sign 
(+) as union operator in the relational algebra. After this 
operation is performed, A will be a new relation produced by 
that operation as its output or result. 
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The relational alcetra basically consists of two groups 
of operators: the set operators union, difference, intersec- 
tion, and product; and the special relational operators 
selection, projection, join, and division. These operations 
are very important in order to understand the other high- 
level relational languages such as SQL, QBE which will be 
discussed later in this Chapter. 

1 • Se t Ope rator s 

The traditioral set operators are union, difference, 
intersection, and Cartesian product. The two relations used 
as operands must he union-compatible for all except 
Cartesian product. This means that each relation must have 
the same number of attributes (same degree) , and the attri- 
butes in corresponding columns must come from the same 
domain (the names of the attributes need not be the same) . 
[Ref. 3;pp, 203-215], [Ref. 6;pp. 242-282] 

-Union 

The union of two relations is formed by combining 
the tuples from one relation with those of a second relation 
to produce a third. In other words, the union of two rela- 
tions A and B, A UNION B, is the set of all tuples t 
belonging to either A or B (or both) . Duplicate tuples are 
eliminated. For example, le t A be the set of officer tuples 
for officers stationed in Monterey, and B the set of officer 
tuples for officers who took course C2. Then A UNION B is 
the set of officer tuples for officers who either are 
stationed in Monterey or took course C2 (or both) . 
-Difference 

The difference of two relations is a third relation 
containing tuples which occur in the first relation but not 
in the second. That is, the difference between two (union- 
compatible) relations A and B, A MINUS B, is the set of all 
tuples t belonging to A and not to B. For example, let A and 
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B be the same sets as in the example under "Union”. Then A 
MINDS B is the set cf officer tuples for officers whc are 
stationed in Monterey and who did not take course C2. 
-Intersection 

The intersection of two relations is a third rela- 
tion containing common tuples. Again, the relations must be 
union-compatible. Mathematically speaking, the intersection 
of two relations A and B, A INTEESECT B, is the set of all 
tuples t belonging to both A and 3. Let A and B again, for 
example, be as in the example under "Onion” above. Then A 
INTEESECT E is the set of officer tuples for officers who 
are stationed in Monterey and took course C2. 

-Cartesian product 

The Cartesian product of two relations is the 
concatenation of every tuple of one relation with every 
tuple of a second relation. let A and B be two relations. 
Then A TIMES B or A x B is the set of all tuples t such that 
t is the concatenation of a tuple "a" belonging to A and a 
tuple ”t" belonging to B. The concatenation of a tuple a = 
(a1,...,aM) and a tuple b = (b1,...,bN), in that order, is 

the tuple t = (a 1 , . . . ,all, bM+ 1 , . . . ,bM+N) . Eor example, let A 
be the set of all officers’ military identification numbers, 
and B the set of all course code numbers. Then A TIMES 3 is 
the set of all possible military_ID_number/course_code 
pairs . 

2. Spe cial P.ela t ional Oper atio ns 
-Projection 

Projection is an operation that selects specified 
attributes from a given relation. The result of the 
projection is a new relation having the selected attributes. 
In other words, the projection operator creates a "vertical” 
subset of a given relation obtained by selecting specified 
attributes, in a specified left-to-right order, and then 
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eliminating duplicate tuples within the attributes selected. 
Projection can also be used to change the order of attri- 
butes in a relation. For example, consider the 
COOHSE_AITENDED relation in Figure 6. 1 (c) . The prcjection 
of COUBSE_aTTENDED cn Ccode and Grade attributes, denoted 
with brackets as COOESE_ATTENDED {Ccode, Grade} , is shown in 
Figure 6.4 Note that although COOSSE_ATTENDED has eight 
tuples to begin with, the projection CODRSE_ATTBNDED {Ccode, 
Grade} has only six. Two tuples were eliminated because the 
tuple {Cl, A-} and {C3, ■ A-} occurred twice (after the 
projection was done) . Another example of reordering the 
attributes within the OFFICER relation is to write a state- 
ment for projection such as OFFICER {City, Name, Rank, Mid}. 



CCODE 1 


GRADE ] 


Cl 


B + 


C2 


A 


C3 


A- 


Cl 


A- 


C2 


B 


C4 


c+ 



Figure 6.4 Projection of COORSE_ATTENDED Relation. 

- Selection 

Ihe selection operator yields a "horizontal” subset 
(rows) of a giver relation. In other words, selection iden- 
tifies tuples to be included in the new relation. Selection 
is denoted by specifying the relation name, followed by the 
keyword WHERE, followed by a conditional statement involving 
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attributes. The condition is a single or a combination of 
Boolean expression (s) . Figure 6.5 (a) shows the selection of 
the relation COURSES WHERE LOCATION = 'MONTEREY*. Figure 6.5 
(b) shows the selection of COURSES WHERE DURATION > 12. 
Figure 5.5 (c) shows the selection of COURSES WHERE DURATION 
> 12 AND LOCATION = ’INDIANAPOLIS*. 
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Figure 6.5 Selection of COURSES Relation. 



-Join 

The join operation is a combination of the product, 
selection, and (possibly) projection operations. The jcin of 
two relations, say A and B, is denoted as A JOIN B which is 
equivalent to taking the Cartesian product of A and E and 
then performing a suitable selection on that product. If 
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necessarj, duplicate attributes can be eliminated by 
projection. The Join operation is a binary operation since 
it operates on two relations but selection and projection 
are operations on single relations (i. e., they are unary 
operations) . 

Actually there are many possible join operations in 
which the "joining condition" is based on equality or 
inequality between values in the common column of two rela- 
tions. Those operations are usually called eguijoin, 
greater-than join, less-than join, and natural join. A 
natural join is an eguijoin with the elimination of dupli- 
cate cclumns, and is a common relational operation. For 
example, the eguijoin and the greater-than join can produce 
the same result as the expressions 

{•A TIMES B) HEERE A. X = B.Y 

(A TIMES B) ^HERE A. X > B.Y 

where A and 3 are relations, and X and Y are attributes 
belong to A and B, respectively. The values of attributes X 
and Y must be derived from some common domain. Consider the 
OFFICER and COURSES relations shown in Figure 6.1 (a) and 

(b) . Tables OFFICER and COURSES may be joined over their 
CITY and LOCATION attributes; the result is shown in Figure 
6.6 We denote such a join as 

{OFFICER JOIN COURSES) WHERE OFFICER. CITY = 
CCDRSES. LOCATION. 

The join in Figure 6.6 is an eguijoin. If the duplicate 
attributes (CITY and LOCATION) were eliminated, then the new 
relation would be created as a result of the natural join 
oper ation. 

-Division 

The division operation has a binary relation R (X,Y) 
as the dividend and a divisor that includes Y. The result is 
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Figure 6.6 Join of OFFICES and COOBSES over CITY and IOC.. 

a set, S, of values of X such that x belongs to S if there 
is a tuple (x,y) in R for each y value in the divisor. 
[Ref. 1:pp. 15-48] 



] 

CCUBSE: COURSE LOCATION: CODES: | 



CCODE 


LOCATION 




LOCATION 


1 CCODE 1 
1 1 


Cl 


Ind .Pol. 




Monterey 


1 C2 1 


C2 


Monterey 




Berkeley 




C3 


Berkeley 






C4 


Monterey 






C2 


Berkeley 







I I 



Figure 6.7 The DIVISION Operation. 

Figure 6.7 illustrates this operation. If relation 
COURSE is the dividend and relation COUESE_LOCATION is the 
divisor, then CODES = COORSE/CODRSE_LOCATION. In the Figure, 
C2 is the only course code for which there is a tuple with 
Monterey and Berkeley (i.e. , <C2, Monterey> and <C2, 
Berkeley>) in COURSE relation. The other course codes. Cl, 
C3, and C4 do not satisfy this condition. 
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C. DATA SDEIAHGOAGES FOE EELATIONAL DATABASES 

The relational database model must provide languages to 
access relations. A number of relational data sublanguages 
(DSLs) have been proposed and developed. Because of the 
tabular structure of relations, users can easily understand 
relational DSLs. Another important feature of a relational 
DSL is its selective power. Relational DSLs should have the 
capability to retrieve data that satisfy any condition over 
any number of relations. [Eef. 1:p. 36] 

Early relational languages were based on selective 
power. Codd [Hef. 12] gave the definition of the relational 
model in 1970 and defined the basis for relational languages 
such as relational algebra and relational calculus. 
Relational calculus has particular significance. It is a 
form of predicate calculus specifically tailored to the 
relational databases and is used to measure the selective 
power of relational languages. A relational language is 
relationally complete if it can produce any data that can be 
obtained from a relational calculus expression. [Eef. 1:p. 
36] 

Data Sublanguage ALPHA, which is based on relational 
calculus, was presented by Codd [Eef. 12]. DSL ALPHA itself 
was never implemented, but a language very similar to it, 
called QUEL, was used as the query language in the rela- 
tional EEHS, called INGRES [Ref. 13]. He will discuss 
INGRES in more detail in Chapter VIII. 

Another widely used Data Sublanguage is Structured Query 
language (SQL) which is used for and is currently imple- 
mented by the System R relational database management system 
that runs on the IBM System/370 [Eef. 14], SQL provides 
retrieval functions and a full range of update operations, 
and also many other facilities. It can be used both frcm an 
on-line terminal and, in the form of "embedded SQL," frcm an 
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application program, batch or on-line, written in either 
COBOL or PI/I. [Bef. 3:pp. 145-156] The basic format, for 
example, of SQL is in the form 

SELECT <attrihute> 

PROM <relaticE> 

WHERE <conditional expression> 

Query-by Example (QBE) is also an another relational 
system designed for users who are not programmers. It has 
approximately the same selective power as SQL but uses a 
graphical interface. It is therefore suitable only for 
terminal use and cannot be embedded in a host language. 
[Ref. 1;pp. 181-200] Query-by Example is an artificial, 
self-contained, user-directed specification language. 

So far we have examined several aspects of database 
systems in general and relational database model in partic- 
ular. But we have net yet answered the following question: 
After having a body of data to be represente.d in a database, 
how do we decide what relations are needed and what their 
attributes should be? This is the database design problem 
which will be discussed in the next Chapter. 
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7II, REIA TIOHA L D ATAB ASE DESIGN 



A. IHTBCDDCTIOH 

Id designiDg relational databases, the primary goal is 
to ensure that relations represent the original data speci- 
fications correctly and without redundancy. The major 
concept for the relational database design is the n oi ma li za - 
tion process, that is, the process of grouping the data 
elements into relations representing entities and their 
relationships. The idea of normalization is based on the 
observation that a certain set of relations has better prop- 
erties following the database operations, such as inserting, 
updating, and deleting, than do other sets of relations 
containing the same data. In other words, the objective of 
normalization is to produce a database design that can be 
manipulated in a powerful way with a simple collection of 
operations while minimizing update anomalies and data incon- 
sistencies [Ref. 15: pp. 99-126]. Normalization theory is a 
useful aid in the database design process, but it is not an 
exact solution. 

B, NCBHAL FORHS 

Normalization theory is traditionally expressed through 
a set of so-called normal forms that progressively constrain 
the structure and contents of a relation. A relation is said 
to be in a particular normal form if it satisfies a certain 
specified set of constraints. 

There are numerous normal forms which have been defined 
by the relational theorists. As shown in Figure 7. 1 
[Ref. 3:p. 239] each of these normal forms contains the 
other. If a relation, for example, is in third ncrmal form 
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(3NF) , then it is automatically in first and second ncrnal 
forms. None of these normal forms will eliminate all anoma- 
lies; each normal form would eliminate just certain anoma- 
lies. But R. Fagin [Eef. 11] defined a new normal form 
called domain/key normal form (DK/NF) , and he showed that a 
relation in DK/NF is free of all modification anomalies, 
regardless of their type. The point is to find ways tc put 
relations in DK/NF. If the database designer does this, then 
he is guaranteed that those relations will have nc anoma- 
lies. Unfortunately, it is net even known if all relations 
can be put into DK/NF. At this point we need the concept of 
functional dependency to define these relational normal 
forms . 

1 • l 2 i£Cti onal Depe ndenc y 

Functional dependency (FD) is a term derived from 
mathematical theory; it relates the dependence of values of 
one attribute or set of attributes on those of another 
attribute or set of attributes. Formally, an attribute (or 
set of attributes) , Y, in a relation is said to be function- 
ally dependent on another attribute (or set of attributes) , 
X, if knowing the value of X is sufficient to determine the 
value of Y. To put it another way, there is only one value 
of Y associated with any value of X. The notation X — >Y is 
often used to denote that Y is functionally dependent on X, 
and is read: X functionally determines Y. The attribute (or 
set of attributes) X is known as the determinant of the FD 
X — >Y. It is obvious that the nonkey attributes of any rela- 
tion are functionally dependent on the key. 

To illustrate the basic principles of functional 
dependencies, consider the sample database in Figure 6. 1 . 
The attribute TITLE in relation COURSES is functionally 
dependent on CCODE because each course has one given title 
value. Thus once a course code is known, a unigue value of 
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Oniverse of relations (normalized and unnormalized) 
First Normal Perm (INF) 

Second Normal Form (2NF) 

Third Normal Form (3NF) 

Boyce-Cedd Normal Form (3CNF) 

Fourth Normal Form (4NF) 

Fifth Normal Form (5NF) 

1 Dcmain/Key Normal Form | 



Figure 7. 1 Relational Normal Forms, 

course title is immediately determined. The FD for this 
example is shown as CCODE — > TITLE. 

likewise, in relation COOESE_ATTSNDED, once values 
for officer ID (MID) and CCODE are known, a unique value of 
GRADE for that officer in that course is determined. This FD 
is defined as MID, CCODE — > GRADE. 

It is convenient to represent the FDs in a given set 
of relations by means of a functional dependency diagram, an 
example of which is shown in Figure 7.2 It is also possible 
to have two attributes that are functionally dependent on 
each ether. In this case both CCODE — > TITLE and TITLE — > 
CCODE hold (because TITLE is an alternate key for the 
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relation CODESES) . The notation CCODE < > TIILE is 

commonly used to illustrate such mutual FD. 



CFFICEE; 



COOESE ATTENDED: 



1 

_J_ 

I aiD I — 

I 

1 



->1 BANK 1 

->1 NAME I 


COUBSES: 

I CCODE l--> 



MID I 
CCODEl 



>1 GEADE 1 



I TITLE I 



— 


>1 CDESCBIPT 1 






— 


>1 DDBATION 1 






— > 


1 

1 




V 




>1 LOCATION 1 



Figure 7.2 Functional Dependency Diagrams. 

Ne also need to introduce the concept of full func - 
tional de pendency. This term is used to show the minimum 
set of attributes in a determinant of an FD. [Ref. 1:pp. 
15-48] Attribute (or set of attributes) Y is said to be 
fully functionally dependent on attribute (or set of attri- 
butes) X if Y is functionally dependent on X and Y is not 
functionally dependent on any proper subset of X. For 
example, in the relation CODBSE_ATTENDED, the attribute 
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GRADE is fully f UDctionally dependent on the attributes 
{MID, CCODE) because it is not functionally dependent on 
either MID or CCODE alone. On the other hand, in the rela- 
tion COURSES, the attribute CDESCRIPT is functionally depen- 
dent cn the attributes (CCODE, TITLE); however, it is not 
fully functionally dependent on those attributes because, it 
is also functionally dependent on either CCODE or TITLE 
alone. 

2. First . Sec ond. Thi rd . and Boyce-C odd Nor mal Forms 

First normal form (INF) deals with the "shape” of a 
record type or a tuple. Under first normal form, all tuples 
in a relation must have the same set of attributes, and the 
attributes must be atcmic (indivisible items) . This defini- 
tion merely states that any normalized relation is in first 
normal form. 

When determining whether a particular relation is in 
normal form, the FDs between the attributes in the relation 
must be examined. For this reason, we will use a notation 
which was first proposed by £Bef. 16] to point out these 
relational characteristics. In the notation, the relation is 
defined as divided into two components; the attributes and 
the FDs between them. The format is 

E = ({X,Y,Z) , {X— >Y,X— >Z}) 

E is the name of the relation, X, Y, and Z are the attri- 
butes, and X — >Y, X — >Z are FDs. For example, in Figure 6. 1 
the relation COUSSE_ATTENDED is defined as 

CODESE_ATTENDED= { {MID, CCODE , GRADE} , {MID, CCODE — >GEADE} ) 

Many update and deletion anomalies can be eliminated 
by converting a relation to second normal form (2NF) . Second 
normal form reguires that all nonkey attributes must contain 
information that refers to the entire key, not just part of 
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it. Id ether words, a relation is said to be in 2NF if and 
only if it is in INF and every nonkey attribute of the rela- 
tion is fully functionally dependent on the primary key. The 
relation ONIT_ASSIGNEE, for example, in Figure 7.3 is in INF 
but not in 2NF because the * nonkey attribute GSTATUS 
(geographical status) is not fully dependent on the primary 
key OCODE (unit code) and HID. Here GSTATUS is fully func- 
tionally dependent on UCODE, which is a subset of the 
primary key. 



Relation; UNIT_ASSIGNED Key; OCODE, HID 



UCODE 


LOCATICN 


GSTATUS 


HID 


DATE 1 


U1 


Honterey 


100 


ID1 


012583 


U1 


H onterey 


100 


ID4 


042385 


U1 


H enterey 


100 


IDS 


012581 


U1 


Honterey 


100 


ID 2 


1 10182 


U2 


Newyork 


20 0 


ID6 


083084 


U3 


Denver 


300 


ID3 


072882 


U3 


Denver 


30 0 


IDS 


100584 


U4 


Newyork 


20 0 


ID1 


031584 



Figure 7.3 Relation in INF but not in 2NF. 

In Figure 7,4 relation DNIT_ASSIGNED has been decom- 
posed into two relations, UNITS and ASSIGNHENT. Both rela- 
tions are in 2NF. Note that the relation UNIT_ ASSIGNED 
suffers from modification anomalies with respect to update 
operations. Figure 7.5 also illustrates the FDs for both 
relations. 

Eroblems occur with each of the following three 
basic operations. 
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ONUS key: OCODE 



OCCDEI 


LOCATION 


GSTATOS 


01 


Monterey 


100 


02 


Newyork 


200 


03 


Denver 


300 


04 


Newyork 


200 



ASSIGNMENT key: MID, OCODE 



MID 


OCODE 


DATE 


ID1 


01 


012583 


ID1 


04 


031584 


ID2 


01 


1 10182 


ID3 


03' 


072882 


ID 4 


0 1 


042385 


IDS 


01 


012581 


IDS 


03 


1 00584 


ID6 


02 


083084 



Figure 7.4 Relations in 2NF. 



ONITS: 

>1 LOCATWN 1 

I OCODE I 



>1 GSTATCS 1 



ASSIGNMENT: 



I MID 1 



1 OCODE I 



— >1 DATE 1 



1 



J 



, Figure 7.5 FD Diagrams for UNITS and ASSIGNMENT. 

Inserting: We cannot enter the fact that a particular unit 
is located in a particular city until at least one officer 
is assigned to that unit. 
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» *( » ffi 




DCL Key: UCODE ULG Key; LOCATION 



UCODE 


LOCATION 




LOCATION 1 


GSTATUS 


U1 


Monterey 




Denver 


300 


02 


Newyork 




Monterey 


100 


03 


Denver 




Newyork 


200 


04 


Newyork 





I 

Figure 7.6 Relations in 3NF. 

The original definition of 3NF was subsequently 
replaced by a stronger definition known as Boyce/Codd Normal 
Form. (BCNF) which can be defined as follows. 

”A relation R is in Boyce/Codd Normal Form (BCNF) if and 
only if every determinant is a candidate key.” 
[Rei. 3;p. 249] 

The original 3NF definition does not satisfactorily handle 
the case of a relation that has more than one candidate key, 
and modification anomalies arise with this definition when 
it is used with such relations. BCNF is often used to remove 
these anomalies. For example, consider the relation 
DNIT_ASSIGNED (Fig. 7.3 ) and the FDs between the attributes 
of that relation such as 

ONIT_ASSIGNED= ( (OCCDE, LOCATION, GSTATUS, MID, DA TE} , 

{UCODI — >LOCATION, UCODE — >GSTAIOS, LOCATION — >GSTATDS, 
UCODE, MID — >DATE} ) 

Here the relation UNIT_ASSIGNED contains three determinants 
but only the determinant (UCODE, MID) is a candidate key. 
Therefore UNIT_ASSIGNED is not BCNF. Similarly, UNITS (Fig. 
7.4 ) is not BCNF, because the determinant LOCATION is not a 
candidate key. On the other hand, relations ASSIGNMENT, UCL, 
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and DIG are each BCNF, because in each case the candidate 
key is the only determinant in the relation, 

BCNF is conceptually simpler than 3NF since it does 
not reference the concepts of primary key, transitive depen- 
dency, and full dependency. Although BCNF is stronger than 
3NF, it is still true that any relation can be decomposed in 
a nonloss way into an equivalent collection of BCNF 
relations. 

3 • Forth and Fifth Normal Form s 

Forth and fifth normal forms deal with multivalued 
attributes. A multivalued attribute may correspond to a 
many-tc-many relationship, as with officers and skills, or 
to a many-to-one relationship, as with the children cf an 
officer. By '*many-to-many” we mean that an officer may have 
several skills and/or a skill may belong to several offi- 
cers. When we look at the many-to-one relationship between 
children and fathers, it is a single- valued fact about a 
child tut a multivalued fact about a father. In some sense, 
UNF and 5NF are alsc related with composite keys. These 
normal forms attempt to minimize the number of attributes 
involved in a composite key. [Eef. 17] 

Forth normal form is based on the concept of multi- 
valued dependency (M7D) . The notation X — »Y is used to 
indicate that a set of attribute Y is multidependent on a 
set of attributes of X. Formally, ilVD is defined as follows: 
Given a relation R with attributes X, Y, and Z, the multiva- 
lued dependency X — >>Y holds in E if and only if the set of 
Y-values matching a given (X-value, Z-value) pair in R 
depends only on the X-value and is independent of the 
Z-value. The attributes X, Y, and Z may be composite. 
[Ref. 3:pp. 237-265] 

Multivalued dependencies which have been defined can 
exist only if the relation R has at least three attributes. 
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the MVD 



It is easy to show that, in the relation E(X,Y,Z), 

X — >>I holds if and only if the MVD A — >>C holds. 

Before giving the definition of 4NF, it is conven- 
ient to state the following theorem proved by Fagin in 
[Sef. 18]. 



"Relation E, with attributes X, Y, and Z, can be 
nonloss-decomposed into its two projections R1 (X,Y) and 
E2(X/Z) if and only if the X-->>Y,Z holds in E." 



Now fourth normal fora (4NF) is defined as follows: 



"A relation R is in fourth normal form (4NF) if and only 
if, whenever there exists an M7D in E, say X — >>Y, then 
all attributes of R are also functionally dependent on X 
(i.e., X — >Z for all attributes Z of R) ." [Eef. 3;p. 
259] 



Fagin also proves (see [Ref. 18] ) that 4NF is strictly 
stronger than 3CNF (i.e., any 4NF relation is necessarily in 
BCNF) , and any relation can be nonloss-decomposed into an 
eguivalent collection of 4NF relations. 

Fifth normal form (5NF) deals with cases where 
information can be reconstructed from smaller pieces of 
information which can be maintained with less redundancy. 
2NF, 3HF, and 4NF alsc serve this purpose, but 5NF general- 
izes to cases not covered by the others. Aho and co-workers 
in 1979 [Bef. 19] discovered relations that cannot be 
nonlosslessly decomposed into two relations but can be loss- 
lessly decomposed intc three or more relations. Because of 
this property, 5NF is also called pro jection- join normal 
form, and is based on the concept of join dependency (JD) 
which is a more general case of an UVD. In general, relation 
R satisfies the JD *(X,Y,...,Z) if and only if it is the 
join cf its projections on X,Y,...,Z, where X,Y,...,Z are 
subsets of the set of attributes of E [Ref. 3;pp- 237-265]- 
We can now define 5NF given by [Eef. 3:p. 262]. 

"A relation R is in . fifth normal form (5NF)-also called 
projection-join normal form (PJ/NF)- if and only if 
every join dependency in R is implied by the candxdate 
keys of R." 
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since a JD is a more general case of an MVD, any relation 
which is in 5NF is necessarily in 4NF. But determining that 
a relation is in 5NF is less straight-forward than 4NF, 
BCNF, etc. because discovering join dependencies is a 
nontrivial task. 

4 . Eomain ^ Ke^ formal Form 

In 1981, R. Fagin [Ref. 11] defined a new ncrmal 
form called domain/key normal form (DK/NF) . In his paper he 
proved that a relation in DK/NF will have no insertion or 
deletion anomalies. He also showed that a relation having no 
modification anomalies must be in DK/NF. DK/NF is based on 
only the concepts of key and domain. These concepts are 
readily known and supported by DBMS products. The definition 
of DK/NF is guite simple. 

"A relation is in DK/NF if every constraint on the rela- 
tion is a logical ccnsecuence of the definition of keys 
and domains." [Ref. 6:p. 299] 

In this definition, constraint is a broad term. Any rule on 
static values of attributes that can be evaluated precisely 
whether or not it is true is said to be a constraint. Thus 
IDs, MVDs, JDs, and edit rules are all examples of 
constraints. Some constraints which have to do with changes 
in data values are excluded from the definition of 
constraint. 

DK/NF relation requires that if keys and domains oan 
be defined such that all constraints will be satisfied when 
the key and domain definitions are satisfied, then modifica- 
tion anomalies are impossible. But there is no known way to 
put a relation in DK/NF automatically. In spite of this 
problem, DK/NF can be extremely useful for practical data- 
base design. DK/NF is a design objective. Database designers 
wish to define their relations such that constraints are 
logical consequences of domains and keys. This goal can be 
accomplished for many designs. 
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Seven normal forms have been discussed and are 



summarized in Figure 7.7 £Eef. 6:p. 305]. 



Form Defining Characteristic 

INF Any relation. 

2NF All nonkey attributes are dependent 

on all of the keys. 

2NF There are no transitive dependencies. 

hNF Every MVD is a functional dependency. 

5NF Join dependencies are satisfied. 

DK/NF All constraints on relations are logical 

consequences of domains and keys. 



Figure 7.7 Sunmary of Normal Forms. 



C. EELATIONAL DESIGN PBOCEDOEES AND CBITEEIA 
1 • D esign Proc ed ures 

The relational model is attractive in database 
design since it provides formal criteria for logical struc- 
ture, namely, normal form relations. In order to produce 
those relations, database designers should choose a design 
procedure. Two different approaches have been proposed: 

” 1 . Decomposition procedures. These commence with a set 
of one or more relations and decompose nonnormal rela- 
tions in this set into normal forms. 

2. Synthesis procedures. These commence with a set of 
functional dependencies and use them to construct normal 
form relations." £Eef. 1:p. 59] 

In practical situations, synthesis procedures are mere 
attractive than decomposition procedures. Many algorithms 
have been proposed for relational design and each algorithm 
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produces relations that satisfy some subset of the rela- 
tional design criteria which will be discussed in the next 
Section. 

Decomposition algorithms start with one relation and 
successively decompose it into normal form relations. The 
relations in 3NF and BCNF are not sufficient for applying 
these decomposition algorithms, so the ideas of M7D and 4NF 
have to be known. Synthesis algorithms, on the other hand, 
start with a set of TEs and syrthesize them into normal form 
relations. In other words, these algorithms use FDs to 
produce normal form relations. Detail information about 
design algorithms can be found in [Ref. 1;pp. 59-88]. 

2 . R elational Database Design C riteri a 

This Section presents several different design 
criteria which have been identified in [Ref- 6:pp, 307-311] 
and [Ref. 16] for producing an effective relational 
database. 

a. Elimination of Modification Anomalies 

The objective of this criterion is to eliminate 
all ancmalies resulting from database- operations . As we have 
seen, if relations are in DK/RF, then no modification anoma- 
lies can occur. This is why DK/NF is a design objective. The 
problem is to find a way that all relations can be put into 
DK/NF. 

t. Relation Independence 

According to this design goal, two relations are 
said to be independent if modifications can be made to one 
without regard for the other. However, this criterion is not 
always achievable. Interrelation constraints allow relations 
to be dependent. To eliminate this dependency the relations 
can be joined together. After the join operation, the new 
relation may have modification anomalies. To eliminate these 
anomalies, relations are decomposed into two or more 



95 



relations; but this cperation creates interrelation depen- 
dencies again. Here we see the conflict in design goals. In 
this case we must choose the least of the evils, based on 
the reguirements of the application. 

c. Ease of Use 

This third criterion for a relational database 
design makes the relations seem natural to users. As far as 
possible, designers should attempt to structure the rela- 
tions so that they are familiar to users. From time to time 
this criterion conflicts with the other two criteria. 

d. Representation 

This relational criterion states that the final 
structure has to correctly represent the original specifica- 
tions. That is, all the relations in the output design 
process must satisfy the conditions for normal form. C. 
Beeri and co-workers have defined three important points for 
the representation of a set of relations. Sin, in the input 
design process by a set of relations, Sout, in the output 
design process (Sin ard Sout are sets of relations used in 
the input and output design processess) : 

”-EEP1: The relations Sout contain the same attributes 
as Sin. 

-EEP2: The relations Sout contain the same attributes 
and the same FDs as Sin. 

-EEP3: The relations Sout contain the same attributes 
and the same data as Sin.” £Sef. 1:p. 63] 

The first representation, REPI, requires all the 
attributes in Sin to also be in the relations in Sout. But 
it does not address any dependencies between the attributes. 

In regard to EEP2, representation requires that each 
FD in Sin be either contained as an FD in one of the rela- 
tions in Sout or derived from the FDs in the relations in 
Sout, using the FD inference rules. 
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The third representation criterion, REP3, also 
requires that the relations in Sout contain exactly the same 
tuples as the original relations in Sin. 

e. Separation 

The separation criterion means that the original 
specifications are separated into relations that satisfy 
certain conditions. As we have discussed earlier in this 
Chapter, the database must be divided into a number of 
normal form relations. 

f . Redundancy 

This last criterion points out the fact that the 
final structure must not contain any redundant information. 
It is possible to define the redundancy criterion in 
different ways. One set of redundancy criteria is shown 
below : 

"-RED1; A relation in Sout is redundant if its attri- 
butes are contained in the other relations in 
Sout. 

-BED2: A relation in Sout is redundant if its FDs are 
the same or can be derived from the FDs in the 
other relations in Sout. 

-EED3: A relation in Sout is redundant if its content 
can be derived from the contents of other rela- 
tions in Sout.** [Ref. l;p. 66] 

Here, RED1 is not a very useful idea, because during deccm- 
position it is often necessary to create separate relations 
that represent FDs between attributes, which may appear in 
other relations. REE2 and RED3, however, can be very useful 
criteria. Any design algorithms should avoid RED 3 because it 
would keep the same data in more than one relation. 

The design criteria discussed in this Section can 
conflict. When conflicts occur, the designer has to assess 
priorities and make the best possible compromise in light of 
requirements. There is no single rule of priority. 
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D. TBANSFORJJIHG THE SDM INTO RELATIONAL HODEL 



Figure 7.8 illustrates the logical design of the 
Personnel database (see SDM in Chapter V). This logical 
schema cannot be used to implement the relational personnel 
database for the following reasons: 

1 . Most of the relations have multivalued attributes. 
Such attributes cannot be used in a relation, 

2. The logical schema allows some tuples to be contained 
in other tuples. The relations must be normalized or 
redefined to eliminate these inconsistencies. 

As shown in Figure 7.8, inversion, matching, and deriva- 
tion have been used to provide interrelationships between 
the attributes. Inverse and match functions must be elimi- 
nated in order to achieve DK/NF. During this process, the 
new interrelation constraints should be added. 

Initially, the relationships between OFFICER and 
ACADEMIC_EDOCATION, MILIT ARY_EDUCATIO N , H EDICAL_ IN FO , and 

FOREIGN_LANGTIAGE were assumed as one-to-many. For example, 
an officer can have more than one medical report, and many 
reports may belong to one officer. Such relationships were 
described by match function in the SDM design. On the other 
hand, relations OFFICER and UNIT have many-to-many relation- 
ships with each other, and these relationships were defined 
by the inverse function in the same SDM. The relationship, 
for example, between unit_assigned and off icer_assigned is 
many-to-many. To eliminate this problem, a new relation 
called ASSIGNMENT has been constructed. 

Ey considering all those conditions, rules, design 
criteria, etc. described in this Chapter, the resulting 
relational design (relational schema) is illustrated in 
Figure 7.9, and domain definitions with attribute/dcmain 
correspondences are shown in Figure 7.10 and Figure 7.11 
respectively. For simplicity, some attributes are removed in 
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OFFICEE (Military ID, Hank, Date_of_r:romotion, Name, 
Birth_dat€, Beginaing date_to_active_duty. 
Native country. Sex, larital_^tatus, NumBer_ 
of children. Permanent address, Current_ 
address, Primary_brancH, Secondary branch, 
Academic_education , Military_educafion - 
Health_ccndition ,Foreign_lan guage_capanility, 
Dnit_assicned) 

Key; Military ID 

Notes: 1. Academic education is a contained 
ACADEMIC_MAJOE tuple, multivalued. 

2. Military education is a contained 
MILIT5EY~ED0 CATION/COURSES tuple, 
multivalued, 

3. Health condition is a contained ME- 
DICAL INFO tuple, multivalued. 

4. Foreign language capability is a 
contained FORSIGTI_LANGaAGE tuple, 
multivalued. 

5. Dnit_assigned is a contained UNIT 
tuple, multivalued. 

UNIT (Dnit_code, Name, Unit_ca tegory. Location, 

Superior_unit, Uni t_f unction. Of f icer_assigned) 

Key : . Unit_code 



Note : 



Oxf icer_assigned is a contained OFFICER 
tuple, multivalued. 



ACAEEMIC_MAJCR ( Academic_br anch, Academic_degree, AID, 

Date, Name_of_universit y) 

Key ; (Academic_br anch, Academic_ degree, AID) 

MILITAEY_EDUCATI01i/C0URSES (Course/Mili tary_school_ 
code, Location, MEID, Course/School_title , 
Duration, Date, Grade) 

Key: (Course/Military school code. Location, 

MEID) 

MEDIC AL_INFO (Medical report number, HID, Date, Height, 
Weight, BlccH pressure. Eye condition, Ear 
condition. Infernal, General_health_status7 

Key; (Medical_report_number, HID) 

FOEEIGN_LANGUAGE (Name of_language, FID, Degree_of_ 

capability) 



Key: (Name_of_language, FID) 



ASSIGNMENT REQUEST (Unit_code, Reguest_nuffiber , Date, 
Primary_branch requested, Secondary_branch_ 
requested, Academic_ma jor requested. Military/ 



course_education_requeste'd, Medical_status, 
Numb er_of_per son , Number_or _req uests) 

Key; (Unit_code, Eeguest_number) 



Figure 7-8 Summary of Logical Design. 
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the relational schema in Fig. 7.9, and they are referred to 
the attribute OTHERS. A sample of the designed database with 
example data is given in Appendix B. 

In order to be familiar with some currently available 
CBMSs, the INGRES lEMS will be introduced in Chapter VIII 
and the sample personnel database in Appendix B will also be 
implemented by using another DEHS known as ORACLE in Chapter 
IX. 



* OFFICER (MID, Rank , Name, Sex, Eri^bran, S ec_bran. Others) 
Key: MID 

UNIT (Ocode,Uname ,Ucat,Dloc,Sup_unit,Uf unc) 

Key: Ucode 

A_ EDUCATION (Abran, Adeg, AID ,Dniv , Gdate) 

Key: (Abran, Adeg, AID) 

M^EEUCATION (Ccode,Cloc, MEID, Cgrade, Cdate) 

Key: (Ccode, Cloc, MEID) 

M_COUFSES (C code, Cloc, C title, Cdesc, Cdur) 

Key: (Ccode, Cloc) 

MEDICAL {Eepno,HII,Rdate, Eyecond, Earcond, Hstat, Others) 
Key: (Repno,HID) 

LANGUAGE (Nlanguage,FID, L degree) 

Key: Nlanguage 

ASGEEC (R_ucode, Regnum, Reqdate, R rank, R_pribr, 

R_secbr,R_acabr,R_miled,R_hstat ,Numof pers) 

Key: (R_ucode, Regnum) 

ASSIGNMENT (AMID, A_ucode , Or derno, Asgdate) 

Key: (AMID, A_ucode, Asgdate) 



Figure 7.9 Relational Schema for Personnel Database. 



100 



DOMAIN NAME 


FORMAT and MEANING 


MID 


numeric 999999999 


BANK 


CHAR (4) ; abbreviations of military 
ranks for the army 


BEB£ON_NAMES 


CHAR (20); names of officers 


SEX 


CHAR(I) ; value is 'M* or ’F» 


BRANCHES 


CHAR (8) ; abbreviations of military 
branches for the army 


DNII_CODE 


CHAR (6) ; unit codes 


DKI'I_NAMES 


CHAR (15); names of units 


DNI3_CAT 


CHAR (4) ; unit categories 

( ’div’ , ’ hosp' , etc.) 


lOCATION 


CHAR (15); names of locations 


aNIT_FDNC 


CHAR (6) ; unit functions 


ACADEMIC BRANCHES 


CHAR (5) ; abbreviations of 




academic branches 


ACAEEHIC_DEGREES 


CHAR(3); value is • BA’ , ’ B S • , ' DR * , 
*MA*,’i1S*, or ’ENG* 




DNI7ERSITY_NAMES 


CHAR (10); names of universities 


lATE 


CHAR (9); format is DD-MMM-YY 


CODESE/SCH_CODE 


CHAR (6) ; course or school codes 


COURSE/SC H_TIT1ES 


CHAR (10); titles of courses 


COUESE/SCH_DESC. 


CHAR (30); description of courses 


CODBSE_GRADES 


CHAR (2) r value is ’ A ’ , ’ A- ’ , ’ B+ ’ , 




’B’ ,’B-’ ,’C+’,’C’,’C-’, 
’D’, *F’ ,’P’, or ’X’ 


EYE_EAR_CONDITICN 


numeric 99; codes for eyes and 
ears 


BEAITH_STATUS 


numeric 99 


lANGDAGES 


CHAR (10); names cf foreign 
languages 


1ANG0AGE_CAP. 


numeric 9 


CRDER_NO 


CHAR (8) ; format is ’999999-9’ 


CIHERS 


subclass of STRINGS where 
specified 


INTEGERS 


numeric values where specified 

- 



Figure 7.10 Domain Definitions. 
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ATTRIBUTE 

AID, AMID, FID, 
HID,MID,MEID 

RANK,B_EANK 

CNAME 

SEX 

EBI BRAN,E PEIBE, 
SECIBEAN,R~SECBE 

A UCODE.R UCODE, 
UCCDE,SDP~nUIT 

DNAME 

OCAT 

UIOC,C10CB 

DFUNC 

ABEAN,E_ACABE 

ADZG 

DNIV 

ASGrATE,CDATE,GEATE, 

BDATE,EEQDATE 

CCOBEA-CCODEE, 

B_HIIED 

CHILE 

CDESC 

CGEADE 

CDDB,NUMOFPEES 

CEDEBNO,REPNO, 

EECNOH 

EYECOND,EAECOND 

HSTAT,HHSTAT 

NIANGDAGE 

IDEGREE 

CIHEES 



DOMAIN 



MID 

RANK 

PEESON_NAMES 

SEX 

BRANCHES 

UNIT_CODE 

UNIT_NAMES 

UNIT_CAT 

LOCATION 

UNIT_FUNC 

ACADEMIC_BEANCHES 

ACADEMIC_DEGEEES 

UNIVEESITY_NAMES 

DATE 

CODES E/S CH_CODE 

COUFSE/SCH_TITLES 

COUESE/SCH_DESCRIPTION 

COOESE_GEADES 

INTEGERS 

OEDER_NO 

EYE_EAE_CONDITION 

HEALTH_STATUS 

LANGUAGES 

LANGDAGE_CA?ABI LITY 
OTHERS 



Figure 7.11 Domains and Attributes for Personnel Database. 
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VIII. I HGRES - 1 RELATIONAL DATABASE SYS TEM 



A. INTRODDCTIOH 

INGRES (Interactive Graphics and Retrieval System) is a 
relational database and graphics system which is implemented 
cn top of the UNIX operating system developed at Bell 
Telephone Laboratories. The implementation of INGRES is 
primarily programmed in "C”, a high level language in which 
UNIX itself is written. Parsing is done by using YACC, a 
compiler-compiler available on UNIX. 

IHGRES runs as a normal user job on top of the UNIX 
operating system. The primary significant modification to 
UNIX that INGRES requires is a substantial increase in the 
maximum file size allcwed. 

In this chapter we shall describe some of the principal 
components of INGRES. These include the query language QUEL, 
INGRES utility commands, and the storage structures 
supported. 

B. QUEL: A RELATIOHAl QOERY LANGOAGE 

QUEL (QDEry Language) is a calculus based language. Each 
interaction of QUEL contains one or more range-statements of 
the form 

RANGE OF variable_list IS relat ion_name 

The purpose of this statement is to specify the relation 
over which each variable ranges. The variable_list portion 
of a RANGE statement declares variables which will be used 
as arguments for tuples. These are called tuple va r iables . 

Each QUEL interaction also includes one or more state- 
ments of the form 
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Ccmmand [ result_name ](tar get_list) 

[TJHERE Qualification] 

Here command is either RETRIEVE, APPEND, REPLACE, or 
DELETE. He use square brackets ([ ]) to denote "zero or 
more". Eor RETRIEVE and APPEND, result_name is the name of 
the relation which qualifying tuples will be retrieved into 
or appended to. For REPLACE and DELETE, result_name is the 
name of a tuple variable which identifies tuples to be modi- 
fied or deleted. The target_list is a list of the form 

result_do main = QUEL Function ... 

Here the result_dcmains are domain names in the result 
relation which are to be assigned the values of corre- 
sponding functions. 

The goal of a query is to create a new relation for each 
RETRIEVE statement. The relation so created is named by the 
"result_name" clause and the domains in that relation are 
named by the "result_domain" names given in the target_list. 
The result_domain name may be omitted and is then taken to 
be the same as the Dcmain_name in the function. The result- 
name is an optional parameter to designate that the table 
returned by the query be permanently stored in the database 
with the result_name as its identifier. Retrievals that 
specify a result_name do not display the result table on the 
terminal screen. The result_name cannot be the name cf an 
existing table. 

Tc create the desired relation, first consider the 
product of the ranges of all variables which appear in the 
target_list and the qualification of the RETREIVE statement. 
Each term in the target_list is a function and the 
Qualification is a truth function, i.e. ; a function with 
values true or false, on the product space. The desired 
relation is created by evaluating the target_list on the 
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subset of the product space for which the Qualification is 
true, and eliminating duplicate tuples. 

The QDEL examples in this chapter all concern the 
following relations. 

CIFICER (HID, RANK, CITY) 

COURSE {CCODE,TITIE,CDESCEIPT,DUR, LOCATION) 
COOESE_ATTENDED (HID,CCODE , GRADE) 

The following are valid QUEL interactions. 

Example 1. Compute duration multiplied by 7 for course 
Wepsys. 

RANGE OF C IS COURSES 
RETRIEVE INTO R 
(DUR_IN_DAYS = C.DUR * 7) 

RHERE C. TITLE = «Repsys" 

Here C is a tuple variable which ranges over the COURSES 
relation, and all tuples in that relation are found which 
satisf '5 the qualification C. TITLE = ”Wepsys”. The result of 
the query is a new relation, W, which has a single domain 
DDR_IN_DAYS that has been calculated for each qualifying 
tuple. If the resulting relation is omitted, qualifying 
tuples are written in display format on the user’s terminal 
or returned to a calling program. 

Example 2. Insert the tuple (ID4,Capt, John, Salinas) into 
OFFICER relation. 

APPEND TO OFFICER (MID = **ID4'’, RANK = '‘Capt", 

NAME = ’'John”, CITY = ’’Salinas”) 

Here the resulting relation OFFICER is modified by 
adding the indicated tuple to the relation. Domains which 
are not specified default to zero for numeric domains and 
null for character strings. 
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Example 3. Cancel all the courses which are given in 
Hontere j. 

RANGE OF C IS CCDESES 

EELETE C WHERE C.IOCATICN = "Monterey” 

Here C specifies that the COOHSES relation is to be 
modified. All tuples are to be removed for which LOCATION 
has the value "Monterey". 

Example 4. Promote all captains to major if the officer 
got the grade ’A' from any course. 

RANGE OF 0 IS OFEICER 

RANGE OF CA IS CCDR SE_A TTENDED 

REPLACE 0(RANK = "Maj") 

WHERE O.RANK = "Capt" AND 

O.MID = CA.MID AND CA. GRADE = "A” 

Here O.RANK is to be replaced by "Maj" for those tuples 
in OFFICER relation where the gualif icat ion is true. 

C. INGRES UTILITY CCHHANDS 

In addition to the above QUEL commands, INGRES supports 
a variety of utility commands. These utility commands can be 
classified into seven major categories. 

1. Invocation of INGRES: 

INGRES da tabase_name 

This command invokes INGRES. ”Database_name" which is 
the name of an existing database. (A database is 
simply a named collection of relations with a given 
database administrator.) This command executed from 
UNIX "logs in" a user, then the user may issue all 
other commands (except those executed directly from 
UNIX) within the environment of the invoked database. 
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2. Creation and destruction of databases: 

CEEATEDB datatase_name 

DESTEOYDB dat atase_name 

These two commands are called from UNIX. The CEEATEDB 
command creates a new INGEES database. The person who 
executes this command becomes the Database 

Administrator (DBA) for the database'. DESTEOYDB 
command removes all references to an existing data- 
base. The directory of the database and all files in 
that directory are removed. To execute DESTEOYDE that 
person must be the DBA for ''datatase_name". 

3. Creation and destruction of relations: 

CEEATE tablename (columnname = format, columnname = 

format,... ) 



DESTEOY tablename 

The CEEATE command enters a new table into the data- 
base. The table is "owned” by the user who invokes 
the command. DESTEOY removes the table from the data- 
base. Only the table owner may destroy a table. The 
columns are created with the type specified by 
"format". The current formats accepted by INCHES are 
1-, 2-, and 4-byte integers, 4- and 8-byte floating 
pcint numbers, and 1- to 255-byte fixed length ASCII 
character strings. 

4. Bulk copy of data: 

COPY tablename (columnname = format, columnname = 

format,... ) intojfrom "filename" 

PBINT tablename 
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The COPY command moves data between INGRES tables and 
standard files. "Ta.blename” is the name of an 
existing table, in general, ”columnname'* identifies a 
column in the table. "Format" indicates the storage 
format for the column's values in the file. To write 
a file, use the "into filename" form of the CCPY 
command. To copy data from a file to an INGRES table, 
use the "from filename" form of the command. The 
PRINT command displays the contents of a table speci- 
fied at a user's terminal under predefined formats. 

,5. Storage structure modification; 

/' 

MODIFY tablename TO storage_structure 

ON {keyl ,key2 , . . . ) 

INDEX ON tablename IS indexname{key 1, key2 , . . . ) 

The MODIFY command changes the storage structure of a 
relation from one access method to another. Only the 
owner of a table can modify that table. This command 
is used to accelerate performance of queries that 
access the table, particularly when the table is 
large or frequently referenced. The storage struc- 
tures currently supported will be discussed in 
Section D of this chapter. The indicated keys are 
domains in tablename which are used concatenated left 
to right to form a combined key which is used in the 
organization of tuples in all but one of the access 
methods. The INDEX command creates a secondary index 
on existing tables in order to make retrieval and 
updating with secondary keys more efficient. The 

secondary key is constructed of columns from the 
primary table in the order given. A maximum of six 
"columnname"s may be specified per index, but a user 
can build any number of secondary indexes for a 
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primary table. Only the owner of a table is allowed 
to create secondary indexes on that table. In order 
to maintain the integrity of the index, users are not 
permitted to update secondary indexes directly. 
However, wherever a primary table is changed, its 
secondary indexes are automatically updated by the 
system. 

6. Consistency and integrity control: 

DEFINE INTEGEIIY ON.range_var IS gual 
DESTROY INTEGRITY tablename (integer ,..., in teg er I all) 
HEIP INTEGRITY tablename 
RESTORE database_name 

The DEFINE INTEGRITY command adds an integrity 
constraint for the table referred to by ”range_var'’ . 
After the constraint is defined, all updates to the 
table must satisfy ”gual". "Qual" must be true for 
every existing row in the table when the INTEGRITY 
statement is issued. Updates that violate any integ- 
rity constraints are simply not performed. 

HELP INTEGRITY command prints current integrity 
constraints on a specified table. DESTROY INTEGRITY 
removes integrity constraints from a table. To 
destroy constraints for a table, the integer argu- 
ments should he those printed by a HELP INTEGRITY 
command on the same table. Only the table owner may 
destroy integrity constraints. 

The RESTORE command checks and cleans up a database 
after an INGRES or operating system crash. RESTORE 
should be executed after any abnormal termination to 
assure database integrity. The RESTORE command is 
only available to the database administrator. 
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7, 



Miscellaneous; 



HELP 

SAVE tablename UNTIL expiration_da te 
PURGE databas6_name 

HELP may be used to print information about INGRES 
features, definitions of views, protections or 
permissions, cr information about the contents cf the 
database and specific tables in the database. SAVE 
is the mechanism by which a user can declare bis 
intention to keep a table until a specified time. 
PURGE is a UNIX command which can be invoked by a 
database administrator to delete all relations whose 
"expira tion_dates” have passed. This should be done 
when space in a database is exhausted. (The database 
administrator can also remove any relations from his 
database using the DESTROY command, regardless of who 
their owners are.) 

D. STORAGE STRUCTURES 

Often the relation (table) will be stored in such a way 
that a complete scan is not required. Also secondary indices 
can be declared and are used if possible to limit the number 
of tuples examined. 

There are five mcdes of relation storage structure. A 
relation owner can decide both storage structure and what 
secondary indices (if any) to construct, then both decisions 
will te done automatically by the system. The five main 
storage structures are; 

1. ISAM : indexed sequential access method structure, 

duplicate rows removed 

2. CISAM ; compressed isam, duplicate rows removed 
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3. HASHED : random hash storage structure, duplicate 

rows removed 

4. CHASH : compressed hash, duplicate rows removed 

5. HEAE : unJceyed and unstructured 

For the first four structures the key may be any ordered 
collection of domains. These schemes allow rapid access to 
specific portions of a relation when key values are 
supplied. The remaining non^keyed scheme (a "HEAP”) stores 
tuples in the file independently of their values and 
provides a low overhead storage structure, especially 
attractive in situations requiring a complete scan of the 
relation. 



IX. lEPlEH EHT ATIOH CF PEESQlJliii DATABASE DSING ORACIE EBMS 

The CEACLE relational DBMS has been used to inplement 
the Personnel Datatase because of its simplicity and 
clarity. SQL is the language that is used to access and' 
control data in an ORACLE database. As a result of this, SQL 
is used as DSL in the database operations such as table and 
view creation, updating data, and in jueries. There are nine 
relations in the Personnel Database. A sample of the 
designed database with example data is shown in Appendix B. 

A relation can be created using CREATE command. An example 
of CREATE command tc create OFFICER’S relation can be as 
follows: 



UFI> CREATE T48LE OFFICER 



( 



•^10 

RAN< 

ONAME 

SEX 

PRI^6RAN 
SEC fdRAN 
OTHERS 



NUH9ER(5) 

CHAR(U) , 
CHAR(9) , 
CHART 1 ) , 
CHARTS) , 
CHARTS) , 
CHARTS) )J 



'JOT NULL, 



Table created. 



After the relation is created, tuples of OFFICER can be 
inserted using the INSERT command. 

JFI> insert INTO OFFICER 

2 XALUEST275S5, 'eaot*, 'Johnson', 'm‘,'arti))',’oilor'); 

1 record created, 

UFI> INSERT INJTO OFFICER 

2 VALU£S(13239,*TTaJ*#*Hernande2* / ‘f»’'r*inftry*,*sDefc*)? 

1 record created. 
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Users of the Personnel Database wish to get seme infor- 
mation by asking the following sample queries. 

1. List all tuples in the relation OFFICER using SELECT 
command. 



UFI> SELECT * 

2 FROM officer; 



MIO RANK ONAME sex oRI*-3RAN SEC*-8RAN OTHERS 



27363 


caot 


Johnson 


m 


a r t i 1 1 


0 i 1 0 1 


12239 


nna i 


Me rnande z 


ti 


t n f t ry 


soe f c 


32958 


1 1 t 


Roob i ns 


f 


a 1 rde f 


ado 


93596 


21 t 


Smith 


m 


medic 


Di 1 0 t 


10999 


1 CO 1 


3 r o^n 


m 


i n f t ry 


ado 


35768 


1 1 1 


Gr eenber q 


m 


s i qc or 


0 i 1 p t 


29369 


caot 


James 


m 


mi 1 enq 


soe f c 


1 6795 


ma i 


Le i qh t on 


m 


f i nanc 


ado 


1 0792 


col 


S tone 


m 


or dnan 


ar t i 1 1 



^ records selected. 



2. list all officers who were assigned between the date 
1-JAN-1966 and 1-JAN-1980. 



UFI> select MID^RANK, ONAME 

2 FROM OFFICER 

3 ^HERE mid In 

« ( SELECT AMID 

5 FROM ASSIGNMENT 

6 /»HERE ASGOATE between M-JAN-66* AND M-JAN-60'); 



MID rank ONAME 



10792 col Stone 
10999 Icol 3rown 
167«5 maj LeiqHton 
27363 caot Johnson 
2936^ caot Jaynes 
12239 maj Mernandez 

6 records selected. 
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3. List military_IDs, ranks# names# 
of all officers who hav^ taken an 'adp' 



and primary tranches 
CO urse. 



UFa> SELECT MI0»RANK,0NAME,PRI«.3RAN 
2 FROM OFFICER 
J -<HERE MID IN 

« ( select MEIO 

5 from m«-EOUCATION 

6 /KHERE CCODEA IN 

7 ( SELECT CCODEB 

8 FROM M4.COURSES 

9 WHERE CTITLE s 'ado* ))} 



Mio rank ONAME PRI«-BRAN 



32^58 lit bobbins airdef 

10999 Ico) Brown inftry 



4. List all unit categories for units. 



UFI> select unique UCAT 
2 FROM unit; 



ucat 

di V 

brg 

deo 

ho3o 

r eg 

bt 

bn 

7 records selected. 
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5. List militar y_IDs , ranks, names, sex, and primary 
tranches for all officers who speak German and took the 
course ’ SS002 * . 



UFJ> SELECT MID, RANK, 0N4ME, SEX, PRIoBRAN 

2 FROM OFFICER 

3 WHERE MID IN 

« ( SELECT MEIO 

5 FROM m^education 

6 where CCODEA s *SS002’ ) 

7 AND HID IN 

8 ( SELECT FID 

9 FROM language 

' to WHERE NLANGUAGE s 'german* ); 



MID rank oname sex PRI^BRAN 



3S7s8 lit Greenberg m sigcor 



6. Order all military_education tuples by 
and within course_ccde put them in descending 
order . 



course_code, 
course_gr ade 



UFI> SELECT • 

2 FROM M4-E0UCATION 

3 ORDER at CCODEA, CGRADE; 



CCODEA MEID CGRADE CDATE 



^^\0^ 


93596 


A0002 


32959 


AS003 


27363 


CS302 


32959 


CS509 


10999 


HS706 


93596 


IA07S 


16795 


IS005 


10999 


IS005 


12239 


OC092 


10792 


SS002 


55769 



A- 12-JUL-9R 
A 23-NOV-92 
0» 13-APR-77 
B* 26-0CT-9a 
A- 31-JAN-77 
A 22-JUN-92 
A- 22-NOV-76 
A n-OCT-70 
A- 30-SE»-72 
A- 01-OEC-b9 
Bt 26-FEB-B2 



1 1 5 



ll records selected 



A view may derive data from more than one relation. This 
is done ty defining a view using a join query. An example of 
a view (view OFFICERHEUC) is shown below. 

7. Create an OFFICEREDOC view from a join of the OFFICER 
relation to the A EDUCATION relation. 



JPI> create view OFFICEREOuCtVlD, rank, vNAME.VBHAN.VDEG, SEX) AS 
2 SELECT MID, rank, ONAME, abRAN,AOEG, SEX 
J FROM OFFICER, At-EDUCAT ION 
<1 /(HERE OFFICER. MIO = A«-E0 DC A T I ON. A I 0; 



'■/iew created. 



8. Count the number of officers who are captain and have 
’BS’ academic degree. 



UFI> select COUNT(RANK) 

2 FROM OFFICEREDUC 
5 aHERE VOEG a *33‘ 

4 ANO rank * 'caPt'; 



COUNT (RANK) 
2 
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9. List all assignments, ordered by assignment date, for 
officer identified by *10792* as MID. 



urj> SELECT MI0,0 NAmE,uname, A3C0ATE 

2 FROM OFFICER, assignment, UNIT 

3 <(H£RE MIO * 107R2 ANO MID 2 AMIO 
fl ANO UCOOE = A*.UCOOE 

5 ORDER av asgoate; 



MIO ONAME UNAME ASGOATE 



10792 Stooe 9th Art 8rg Ol-SEP-66 

^ 10792 Ston« 2nd Inf Oiv U-JAN-71 

10792 Stone 69th Ord Deoot lS«APR-78 



Of 



10. List all officers and courses for officers in 
the courses with duration of at least one year. 



terms 



-I> SELECT R&Nh, ONAME. C0£SC,CLDCH,COUR 

2 FROM OPFlCER,MrcnuRSES,M*-EDuCATION 

3 «M£RE MO : m£I0 

a AND CCDOEA = CCOOEB 
5 AND CDJR >- 52; 



4NK 


ONAME 


COESC 


CLOC0 


CDU-R 


1 t 


Smith 


Aca* of Health Sci* 


Ft .Houston, TX 


96 


1 t 


Smith 


Apmy Aviation School 


Ft .RuckerfAL 


53 
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11. Compute and display the sum of duration of course (s) 
which was taken by officer 'Smith'. 



UFI> select SUH(CDUf») 

2 FROM OFFICER, M*-COURSES,M*-EOUCATION 

3 (itHERE MIO = MEIO 

(I 4N0 ONAME = ’Snith' 

5 AND CC30EA = CCOOEB; 



SUM(CDUR) 
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12. List all officers a 
rank, officer name, milit 
assignment reguests where 
reguirements specified in t 



nd assignment reguests, including 
ary_ID, and reguest number, for 
officers* specialties meet the 
hat request. 



UFI> select REQNUM,M10,RA^JK,0'gAME 

2 FROM OFFICER, ASGRE0,a«-EDJCATI0N,M4-EDUCAT10M, MEDICAL 

3 «HERE mid = MEIO 



a 


AND 


'^ID = AID 


5 


AND 


MID = HID 


6 


AND 


PRU3RAN = R««PRIBR 


7 


AND 


SEC«-3RAN = R«‘SECBR 


8 


AND 


A9RAN s R«-ACABR 


9 


AND 


CCOOEA = R«*MILE0 


10 


AND 


HSTAT <= R^HSTAT; 



REONUM 


MID RANK 


ONAME 


527685-U 


12239 maj 


He pnai 



051084-3 16745 maj Leighton 
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I. FOHCTIO HS CF A DATABASE HA NAGEMEMT SY STEM 



A. INTBCDDCTIOH 

The principal function of the DBMS is to store, 
retrieve, and modify data. However in an operational envi- 
ronment the DBMS should provide other important functions. 
In this chapter, we will first describe major DBMS functions 
and then discuss three of these functions in detail : 
recovery, concurrency, and security. 

Major DBMS functions are described by Codd, E.F. in 
[Ref. 20:p. 114], and they are shown in Figure 10.1. 



1. Store, retrieve, and update data. 

2. Provide recovery services in case of failure. 

3. Provide concurrency control services. 

4. Provide security facilities. 

5. Provide integrity services to enforce database 
constraints. 

6. Provide a user-accessible catalog of data 
descriptions . 

1 . Support logical transactions. 

8. Interface with communications control programs. 
S. Provide utility services. 



Figure 10. 1 Major Functions of a DBMS. 

The first and fifth functions have been discussed in 
previous chapters. Recovery, concurrency control, and 
security facilities will be discussed later in this chapter. 
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The management of large, complex databases is difficult. 
Maintaining a database with ten record types and hundreds of 
data-items can be time-consuming. If a database is processed 
by hundreds of application programs then changes of records 
and data-items can be risky. Questions like "Which programs 
are affected by a change to eight-digit 
Unit_Iocation_Codes? " or "Which records contain MID?" are 
frequent. Since most databases are self-describing, much of 
the data needed to answer these questions are stored within 
the database. However, these information may not be readily 
accessed by humans. For that reason, "a user-accessible 
catalog" which contains data descriptions and data about the 
relationship between programs and data will be very useful 
to the user, and it should be provided by DBMSs. 

A l ogical tran s action is a sequence of activities 
performed atomically. Usually, transactions include several 
actions on the database. Unfortunately, the DBMS product 
cannot know which groups of actions are logically related. 
Thus the DBMS must provide facilities for the application 
programmer to define transaction boundaries which are needed 
in handling concurrent control and recovery functions. 

In addition to these functions, the DBMS must interface 
with a co m mun i catio ns control sub system which controls the 
flow of transactions to application programs from the DBMS. 
Finally, the DBMS must provide u tilit y programs to facili- 
tate database maintenance. These utility programs may be 
used to unload, reload, and execute the database; or they 
may be used to make mass insertions or deletions of data in 
or out of the database. 

No current DBMS provides all of these functions in a 
satisfactory way. These capabilities can be used as a 
checklist of decision criteria for a DBMS. A system that 
does not provide most of them is not truly a DBMS. 
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B. EBC07EBI 



Computer and database systems can fail in many ways. 
Computers stop unexpectedly, disk heads crash, operators may 
drop disks, programs may have bugs, and so on. Database 
systems must include not only a variety of checks and 
controls tc reduce the likelihood of failure, but also an 
extensive set of procedures for recovering from the failures 
that will inevitably occur despite those checks and 
controls. 

In an operational environment there are many possible 
causes of failures, such as: 

- programming errors; in an application or in the data- 
base system, 

- hardware errors; on the device or the channel or the 
CPU, 

- operator errors; such as mounting a wrong tape, 

- fluctations in the power supply, 

- fire in the computer system room. 

If such errors occur during a database interaction, the 
database can be left in an inconsistent state. Recovery 
software is used to restore the database to some previous 
consistent state. 

1 • Ee cover y v ia Reprocessing 

Ihere are a variety of recovery algorithms. Ihe 
simplest way is to keep back-up a copy of a database. This 
copy is created periodically, once or twice a day. Ihen, 
when a failure occurs, the last back-up copy is used to 
restore the database. Any transactions since that copy was 
made are run again. This algorithm is called "recovery via 
reprocessing" and it has several drawbacks. First, repro- 
cessing transactions takes the same amount of time as 
processing them the first time. This means that one day will 
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fce required to recover one day of processing. If the system 
is heavily loaded, the system may never catch up. Second, 
when transactions are processed concurrently, it is impos- 
sible to guarantee that they can be reprocessed in the same 
order as they were originally processed. For these reasons, 
reprocessing is not a viable form of recovery. 



2 • Tr a nsaction s 

The fundamental purpose of the database system is to 
prpcess transactions. A transaction is a program, or a 
program part, that can read frcm or write into the datatase. 
It consists of the execution of an application-specific 
sequence of operations. These operations can be of five 
types: BEGIN TRANSACTION, READ, WRITE, COMMIT, and 

ROLLBACK. All transactions tegin with BEGIN TRANSACTION 
operation. READ causes a page or record to be read from the 
database. WRITE causes a new copy of a page or record to be 
written into the database. COMMIT tells the system that the 
transaction has terminated succesfully and that all of its 
updated pages or records should be permanently reflected in 
the database. ROLLBACK tells the system that the transaction 
has terminated abnormally and that the records or pages it 
wrote into should be returned to their previous state. A 
transaction can have only one COMMIT or ROLLBACK processed, 
and transactions cannot be nested. 

The r ecov ery manage r processes the READ, WRITE, 
COMMIT, and ROLLBACK commands. It also handles system fail- 
ures so it provides reliability for the DBMS. 

3- Rec over y via Bollback/Bollf orwar d 

This approach uses the following four step 
algorithm: 
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1 . 



Eecreate the outputs of all successfully completed 
transactions. (Transactions which are ended with 
CCHHIT operation.) 

2. Atort all transactions in process at the time of 
failure. 

3. Remove database changes generated by aborted trans- 
actions. 

4. Restart aborted transactions. 

This algorithm will appropriately recover the data- 
base. Some transaction outputs cannot be undone. This 
outputs are called "Real outputs” by Gray in [Ref. 21:pp. 
223-242]. Real outputs are messages which are received by 
people who are using the system, like order confirmations or 
inputs to other transactions. The message 

"OFFICER, (MID: 9999999) , IS ASSIGNED TO THE DNIT, 
(UNIT_ID:9999) , ASSIGNMENT ORDER NO IS 99999-9" are examples 
of real outputs. Because they cannot be undone, real outputs 
should net be produced until the transaction is completed. 
It is recommended that a log of real outputs be maintained. 
When the transaction is completed, the actions onthe leg are 
updated and the real outputs become visible. If a failure 
occurs when the real cutputs are being produced, each output 
could be numbered and a log kept of the real outputs that 
have teen produced. 

4 . Tr a nsactio n legging 

To apply ONDO (rolling back a transaction) and REDO 
(rcllfcrward a transaction) processes to a database system, 
a log should be kept of transaction results. The log 
includes the old and new values of all items updated by the 
transaction, and it is in chronological order. The log 
resides on either disk or tape. When a failure occurs, the 
log is used to both ONDO and REDO transactions, as shewn in 
Figure 10.2 and Figure 10.3, respectively. 
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DATABASE 








WITH CHANGES 










DATABASE 






{ UNDO ) > 
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WITHOUT CHANGES 




— 

1 BEFORE IMAGES! 











Figure 10.2 ONDO Transaction Procedure, 



DATABASE 
HIIHOUT CHANGES 



I AFTER IMAGES! 



EEDO^ >j 



I DATABASE 



HITH CHANGES 



Figure 10.3 BEDO Transaction Procedure. 

To UNDO a transaction, the log must contain a copy 
of every database reccrd before it was changed. Such records 
are called before images . By applying before images tc the 
database an UNDO prccedure is performed. To REDO a trans- 
action the log must contain a copy of every database record 
after it was changed. These records are called after im ages . 
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By applying after images to the database a REDO procedure is 
performed. Possible data-items of a transaction log are 
shown in Figure 10.4. 









• 




Transaction ID 


Operation Type 






Reverse Pointer 


Object 






Forward Pointer 


Old Value 






Time 


New Value 













Figure 10.4 Data-items of a Log Record. 



For identification purposes each log transaction has 
a unigue ID. All images are linked together with a double- 
linked list. These forward and backward links can be used by 
the recovery manager to locate all records for a particular 
transaction. Other data-items are: the time of the action, 
the type of the operation (modify , insert, etc.), the object 
such as record type and identifier, and the old and new 
values. 

5 . ^<i rite- a head Icq 

There is an interval between writing a change to the 
database’s stable storage and writing the log record repre- 
senting that change. These are two distinct operations. This 
fact introduces two questions: What happens if a failure 
occurs in the interval between these two operations? What 
should be done to avoid improper applications? 

Suppose that in fact such a failure does occur, so 
that only one of the writes (the first operation) is 
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performed and the other is lost. If the performed operation 
is the database write, there will be changes in the database 
that are not recorded in the log so the UNDO process is not 
possible for these changes. It is obvious that, for safety, 
the leg record should always be written first. Therefore we 
can define the write- ahead log pr otocol as follows: 

1.' A transaction is not allowed to write a record to the 
stable storage of the database until at least the 
before image cf the log record has been written to 
the physical leg. 

- 2. A transaction is not allowed to complete CCMMIT 
processing until both the before images and the after 
images of all log records for the transaction have 
teen written tc the physical log. 

If a failure occurs, a change may be recorded in the 
log and not in the database. In this case, the recovery 

manager may attempt to undo changes that have not yet 

cccured. This is not a problem, because the recovery manager 
will only be placing before images in the database. Records 
will be replaced by copies of themselves. This is a wasteful 
operation but not harmful. 

C. CCHCDBBEHCY CONTECl 

Given a correct state of the database as input, a 

correct transaction will produce a correct state cf the 

database as output. Even if all transactions are individu- 
ally correct, however, it is possible in a multiuser system 
for transactions that execute concurrently to interfere with 
one another in such a way as to produce an overall result 
that is not correct. As an example of that kind of interfer- 
ence, we will consider the ’’lost update” problem. 
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• Concurrent O^^te {Lost Dpda te) Pr oblem 

Ihe lost update problem can be represented as shown 
in Figure 10.5. 




Figure 10.5 lost Update Problem. 



Transaction A is intended to change some field F in 
tuple i; lets say will double the value of field F. 
Transaction B is intended also to double the value of that 
same field. Thus, if the initial value of that field is 2 , 
then running the two transactions one at a time, without 
concurrency, will produce a final result of 8. However, the 
particular concurrent execution sequence shown in Figure 
10.5 produces a final result of 4. That particular execution 
sequence is therefore incorrect. In this situation, we can 
say that TA*s update is lost because TB overwrites it. 

2 . Ee s ource Loc king 

The most common method of concurrency control is to 
use locks. One lock is maintained for each user. The term 
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use r refers to -the user of DBMS, not necessarily the system 
user. Thus a user can be either a person using the DBMS 
guery/update facility via a terminal, or an application 
program that calls upon the DBMS for service. A pregram 
obtains all such locks before making any updates. 
Concurrency control must ensure that at most one program 
gets the lock for one database part. Hence, if a program 
wishes to move a locked, item to the program working storage, 
it must wait until the previous program releases the lock. 
The inplementa tion of this process differs from one system 
to- another. In many implementations, user programs include 
commands to lock the required records before updating them. 
This can be represented pictorially as shown in Figure 10.6. 



Time 



Transaction A (TA) 



Transaction E (TE) 



* 

* 

t1 

♦ 

* 

t2 

t3 

t4 

t5 

t6 

tl 



lock El. Copy tuple 
1 fron relation R1 

♦ 

♦ 

modify tuple 
and update 



release 



R1 

* 

♦ 

♦ 

♦ 

♦ 



♦ 

* 

attempt to place a 
lock on El 
wai t 
wait 
wai t 
wait 
wai t 

lock R1. Copy tuple 
i from relation El. 

modify tuple i, and 
update 

release El 



Figure 10.6 Resource Locking. 



128 



It is seen that transaction B is now made to wait at 
time t2/ because its request for a lock on R1 at that time 
conflicts with the Icck already held on Hi by transaction A. 
Transaction 3 resumes after transaction A releases its 
lock. This kind of lock mechanism will provide a correct 
final result for those two transactions. Lost update prob- 
lems can be solved by the lock mechanism. 

3 . Deadlock 

locks can introduce the problem commonly known as 
deadlock. A deadlock occurs when two transactions, say TA 
and TE, each places locks on relations, say HI and R2 
respectively, and then each transaction attempts to place a 
lock on the others already locked relation. The order of 
processing can be as shown in Figure 10.7. 



Time 


Transaction 
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a lock on R 
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wait 




wait 






wait 




wait 





Figure 10.7 Deadlock Problem. 
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Both transactions are then waiting for each other to 
release a lock. In the database environment, the usual step 
to resolve cr "to break" the deadlock is to rollback one of 
the programs. Breaking a deadlock consist of chocsicg a 
"victim", one of the deadlocked transactions; and rolling it 
tack. The victim is not necessarily the transaction that 
actually caused the deadlock; it may be the one holding the 
fewest locks, or the one that was most recenly started, or 
the cne that has made the fewest updates. The rollback 
process involves the following jobs: 

-1. Terminate the transaction, victim, and undo all of 
its updates. 

2. Release all the locks of the transaction; resources 
are now allocated to other transactions. 

^ Granularity 

So far, in our examples, we assumed that the unit of 
locking is the individual record. However, the level of the 
lock can be different in different applications, or in 
different DBHSs. Locks, at the highest level, can be applied 
to an entire database. This strategy is used by DBMS prod- 
ucts that invoke tie lock for a short time during the 
processing of a single database reguest. Locks can also be 
applied, at the lowest level, to a specific field within an 
individual record. In between these extremes, locks can be 
placed on records, on pages or blocks, and on files. As 
usual, there are tradeoffs among these alternatives. A lock 
of the entire database is simple for the DBMS to manage. 
However, throughput may be slow because of less concurrency. 
On the other hand, locks of small granularity will be 
complex to manage but throughput will tend to be faster 
because of more concurrency. The choice among alternatives 
depends on requirements. 
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B. DAIAEASE SECORITI 



The security in databa'se environment is protection of 
the database against unauthorized disclosure, alteration, or 
destruction. The subject of database security has many 
different aspects and approaches, such as physical protec- 
tion, hardware controls, using passwords, or using authori- 
zation tables. Here we are concerned primarily with 
restricting certain users so they are allowed to access 
and/or modify only a subset of the database. 

Good security means that people have access to the data 
that they need to accomplish their job function, and no 
more. Job functions vary, and for that reason data access 
authorizations will vary. A table called a uthorization rules 
is used for that purpose, and was developed by Fernandez, 
Summers, and Wood in [Bef. 22:p, 5]. 

Authorization rules are compiled and stored in the 
system dictionary. First, these rules will be entered into 
the system, then they will be enforced. The authorization 
rules compiler and the corresponding enforcement mechanism 
together make up the security subsyste m . 

In the application environment it is convenient to use a 
matrix fcr authorization rules. The matrix is called an 
auth o rization m atri x in which rows correspond to users and 
columns correspond to data objects. The entry A[i,j] repre- 
sents the set of authorization rules that apply to user i 
with respect to data object j. An example of an authoriza- 
tion matrix is shown in Figure 10,3. 

Sophistication of the security subsystem can be measured 
by the granularity of the objects. For example, some DBMS 
systems support authorization only at the level of whole 
relations, others permit authorization at the level of indi- 
vidual fields. In ocr example authorization is based on the 
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DATA 0EJECT1 
{ OFFICER 
relation ) 


DATA 0BJECT2 
(UNIT 

relation ) 


DATA OBJECT! 
( COURSES 
relation ) 


DSER1 

(Brown) 


ALL 


ALL 


ALL 


0SEE2 

(John) 


NONE 


NONE 


NONE 


USER3 
(Fersonel 
Office ) 


ALL 


READ 


READ 

UPDATE 


DSER4 
(Frog-3 ) 


NONE 


READ 


READ 


DSER5 
(Education 
Office ) 


READ 

UPDATE 


READ 


ALL 



Figure 10.8 An Example for Authorization Matrix. 

names ci objects and not on their value. This is called 
val ue -in depend e nt con tro l. In this schema, the system can 

enforce the controls without having to access the data 
objects themselves. It is also possible to provide v alue- 
depe ndent c ontro l in that we can extend the entries in the 
matrix to include an optional acces s pre dicate . For 
example, the entry 
SELFCT * 

FECM OFFICER 
^?HESE RANK = ’CAFT* 

might be used to allow SELECT access to some officers and 
not others. 
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Authorization rules can also specify that certain field 
combinations are prohibited, even though the individual 
fields within the combination may be accessible. It is also 
necessary to control access to programs. Moreover, it is 
important to control access to the authorization matrix 
its elf. 
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XI. COHCIDSIONS 



Information is a fasic resource, like people or money, 
for an enterprise, and it should have a professional manage- 
ment group that is responsible for its effective use 
throughout the enterprise. For achieving this task, a new 
staff function called information resource management (IRM) 
has been proposed. This function, in most cases, should 
establish policies and procedures to guide users, system 
developers, and managers so that their decisions will be 
consistent and compatible and employ the best in currently 
available technology. In a DBMS, this function is referred 
to as Database Administration (DBA). [Bef, 15:pp. 168-183] 
Cn the other hand, the personnel administration function 
for managers of an organization must have complete control 
over evaluating, assigning, and firing their own employees. 
In order to perform this task satisfactorily and effec- 
tively, the managers have to make their own decisions very 
accurately. Sometimes, they are forced to make such deci- 
sions in a short period of time. Those factors in a powerful 
personrel management can be provided by having a well- 
designed personnel database and a suitable DBMS. 

James F, Fry and Edgar H. Sibley state in their 1976 
paper [Bef. 23] that the objectives of database management 
are ; 

-to make an integrated collection of data available to a 
wide variety of users (data availability), 

-to provide for quality and integrity of the data (data 
quality) , 

-to Insure retention of privacy through security meas- 
ures within the system (privacy and security). 
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-to allow centralized control of the database which 
is necessary for efficient data administration 
(management control) , and 
-to provide a higi degree of data independence. 
Considering those major objectives and some advantages 
such as simplicity, ease of use, data independence, and 
theoretical foundation, the relational database model has 
been found to be convenient in designing such a personnel 
database system. The other database models are more complex 
and more difficult to implement. 

, After the organization's requirements are understood, 
the process usually begins by choosing the data model that 
seems most appropriate and then proceeding to a detailed 
evaluation of only the available DBMS products that support 
the selected model. This is the problem of choosing a DBMS. 
Several committees are working on this problem such that all 
DBMS's provide the same functions and the same interfaces 
will be standard. In this thesis, the ORACLE DBMS is used to 
show the implementaticn stage of the personnel database. 

In conclusion, it is useful to emphasize that it is not 
only important to design an efficient database for an enter- 
prise but also it is required to maintain and develop the 
database by permanently monitoring its performance to 
maximize efficiency as a final operational responsibility of 
the database administration (DEA) . 
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SEBANTIC DATABASE DESIGN 



The detailed description of the Semantic Datahase Model 
(SDM) design for the Personnel Database which is mentioned 
in Chapter V is shown below. 
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OIFICEE 

description: All officers who are on active-duty, 

member attributes: 

Military_ID 

description: A unique number for each officer 

value class: HID 

mandatory 

not changeable 

Rank 

value class: RANK 

Date of_pro motion ' 
value class: DATE 

Name 

value class: PERSON_NAMES 

Birth_date 

value class; DATE 

Beginning date_to active-duty 

description: Date of first day of being on 
active-duty . 
value class; DATE 

Native_country 

value class: COUNTRY 

S 6X 

value class: SEX 

Harital status 

value~class: MARITAL_STATUS 

Number_of children 

value class: INTEGERS 

Permanent address 

value class: ADDRESS 

Current_ad dress 

value class: ADDRESS 

Primary_branch 
description: 
value class: BRANCHES 

Secondary branch 
description: 
value class: BRANCHES 

Academic education 

value class: ACADEHIC_HA JOR 
match : Academic fcr anch/Academic degree of 
ACADEMIC^MA JOE on AID. “ 
multivalued 



Figure A.1 SDH Design for Personnel Database. 
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Military education/courses 

value class: MILITAHI_EDDCATION/COORS ES 
match : Course/Military school code of 

MILITARY_EDDCATrON/COaESES on MEID. 
multi val ued 

Health condition 

value class: MEDICAL INFO 
match : General health status of 
HIIICALIINFC on HID. 

Foreign language capatility 
value“class: F0RE1GN_LANGQAGE 
match : Foreign .language of 

FOREIGN“LANGDAGE on FID. 
multivalued ~ 

Dnit_assigned 

descripticr: Units which the officer has teen 
assigned until current date, 
value class: UNIT 
inverse : Of ficer_assigned 
multivalued 

identifiers : 

Military_ID 



ACAEEMIC_MAJOR 

description: lype of academic branch, the degree 
earned for that branch, location 
and name of the universty which 
the officer attended. 

member attributes: 

Academic branch 

description: Branch such as Computer Science, 
Electrical Engineering, 
value class: ACADEMIC_BR ANCHES 

Academic_degree 

description: Degree such as Bachelor of 
Science, Master of Science, 
Engineering, Doctorate, 
value class: ACADEMIC_DEGREES 

AID 

description: Military ID of the officer who 
earned that degree, 
value class: MID 
mandatory 

Date 

description: Date at which the degree earned 
value class: DATE 



Figure A. 2 SDM Design for Personnel Database (cont'd-). 
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Name of university 

value“class: UNIVEESITI_NAMES 

Location of university: 
value class: COONTBi 

identifiers: 

Academic_brancii + Academic_ degree + AID 



HILITARY_EDOCATICN/CODESSS 

description: Information about the military 

school graduated or military course 
attended, location of school, grade 
and date of graduation. 

member attributes: 

Course/Hili tary school code 

value class: COOESE/5CHOOL_CODE 

Location 

value class: COONTHI 



MEID 

description: Hilitary_ID of the officer who 
attended the school or course, 
value class: HID 
mandatory 



Course/Schocl title 

value class? COUESS/SCHOOL TITLES 



Description 

description: Textual explanation of the course 
value class: COOESE/SCHOOL DESCRIPTION 



Duration 

description: Duration of the military 
education in weeks, 
value class: INTEGERS 



Date 

description: Graduation date of an officer 
from the course or school, 
value class: DATE 



Grade 

descripticr: Grade earned for that course 
or military education, 
value class: C0URSE_GEADES 

identifiers 

Course/Hilitary school_code + Location + MEID 



Figure A. 3 SDH Design for Personnel Database (cont’d.). 
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MEEICA1_INF0 

description: Medical information and overall 
medical status for an officer. 

member attributes: 

Medical repcit_number 

descrlpticr: Medical report number of last 
checking or the officer. 



value class: 


REPORT_SOMBER 


HID 

description: 


Military ID of the officer to 
whom the information belongs to. 


value class: 
mandatory 


HID 


Date 

description: 
value class: 


Date of the report. 
DATE 


Height 

description: 
value class: 


Height of the officer. 
HEIGHT 


Weight 

description: 
value class: 


Weight of the officer. 
WEIGHT 



Blood_pressure 

value class: BLOOD EEESSORE 



Eye condition 
description: 


Describes the condition of both 
eyes of the officer. 


value class: 


EYE_CONDITION 


Ear condition 
description: 


Describes the condition of both 
ears of the officer. 


value class: 


EAR CONDITION 


Internal 





description: Describes the condition of 

internal organs of the officer, 
value class: INTEENAL_COHDITION 

General_health_status 

description: An overall evaluation of 

conditions of all body parts. 
This status is described by some 
member attribute values of this 



value class: 


entity class. 
HEALTH STATUS 



Figure A. 4 SDM Design for Personnel Database (cont’d.). 



140 



identifiers: 

Medical_report_number + HID 
rOEEIGN_LANGOAGZ 

description: It is used to define the officers 
fcreign language capability. 

member attributes: 

Foreign language 

value“class: LANGUAGES 



description: Military ID of the officer who 
has the language capability, 
value class: MID 
mandatory 

Degree of capability 

value class: LANG0AGE_CAPABILITY 

identifiers : 

Foreign_language + FID 



DNII 

description: Eescription of a unit. Unit code^ 
unit name, unit categori, location, 
superior unit, unit status and 
officers assigned to the unit. 

member attributes: 



Unit code 

value class: UNIT_CODE 

mandatory 

not changeable 



Name 

value class: UNIT NAMES 



Unit_category 

description: Organizational level of unit 
such as corps, brigade, 
division. 

value class: UNIT CAT 



Location 

descripticr: Location of unit, 
value class: UNIT LOCATION 



Figure A. 5 SDH Design for Personnel Database (cont’d.) . 



Superior_unit 

aescription; The unit which has command and 
control of this unit, 
value class: ONIT 

Dnit_f uncticn 

description; Type of function or service which 
the unit performs, 
value class: 0NIT_FDNC 

Of ficer_assigned 

description: Officers who are assigned to this 
unit. 

value class: OFFICER 
inverse : Onit_assigned 
multi val ued 

identifiers : 

Unit code 



ASSIGNMENT_REQUE£T 

description: The request which is made by any unit^ 
about officers who have certain 
specifications fit for a specific 
position to be assigned. 

member attributes: 

Dnit_code 

description: The unit who is issued the 
request for assignment, 
value class: UNIT_CODE 
mandatory 
not changeable 

Eequest_number 

description: A number which is given by the 
unit who is issued the request, 
value class: REQUEST_NO 
mandatory 
not changeable 

Date 

value class: DATE 
Rank 

description: Rank of the officer who is 
requested for assignment, 
value class: RANK 

Primary branch requested 
value'class -.“BRANCHES 



Figure A. 6 SDH Design for Personnel Database (cont*d.). 
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Secondary tranch requested 
value class: BHANCHES 

Academic_ma jor_reguested 

description: Academic major and degree for 
this assignment 
value class: ACADEMIC_flAJOE 
multivalued 

Military_course/educa tion requested 

descripticr: Military education and/or course 
which is needed for this 
assignment. 

value class: MILITAEY_EDOCATION/COUESES 
multivalued 

Medical_status 

description; Lowest value for medical status 
which is needed for this 
assignment. 

value class: HEALTH_STATDS 

Number_of person 

description: Number of officer requested with 
this assignment request, 
value class: INTEGEBS 

class attributes: 

Number_of requests 

description; The number of requests that 
issued in the current year, 
derivation: Number of members in this class 
which Date= current year. 

identifiers; 

Dnit_code + Eequest_number 




Figure A. 7 SDM Design for Personnel Database (cont’d.) . 
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HID 

interclass conrection: sabclass of STRINGS where 
format is 5 digit numbers 



SANK 

interclass connection: subclass of STRINGS where 
specified 



DATE 

interclass connection: subclass of STRINGS where 
format is: 

month: number where >1 and <12 

11 ..II 

daj^: number where integer and >1 and <31 

year: number where integer and > 1 900and<2000 
where (if (month =4 or =5 or =9 or =11) then 

day < 30) and (if month =2 then day <29) 
ordering by year, month, day 

EERSON_NAMES 

interclass connection: subclass of STRINGS 



COUNTRY 

interclass connection: subclass of STRINGS where 
specified 

SEX 

interclass connection: subclass of STRINGS where 
format is 1 character: m, f 

KAEITAL_STATOS 

interclass connection: subclass of STRINGS where 
format is 1 character: S, M, D, 

ADDRESS 

interclass connection: subclass of STRINGS 

TRANCHES 

interclass connection: subclass of STRINGS where 
specified 

ACAEEHIC BRANCHES 

interclass connection: subclass of STRINGS where 
specified 

ACADEMIC DEGREES 

interclass connection: subclass of STRINGS where 
values are: BA, BS, MA, MS, ENG, PhD 

DNIVERSITY_NAMES 

interclass connection: subclass of STRINGS 

CO OR£E/SCHOOL_CODE 

interclass connection: subclass of STRINGS where 
format is 5 characters 



CODESE/SCHOOL_TI1LES 

interclass connection: subclass of STRINGS 



Figure A. 8 Domains of Attributes. 
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COOBSE/SCHOOL_DE£CRIPTION 

interclass connection: subclass of 

CODESE_GRADES 

interclass connection; subclass of 
format is 2 characters 



EEPORT_NDMBER 

interclass connection; subclass 
format is 6 digit number 

BEIGHT 

interclass connection: subclass 
format is positive integer 



WEIGHT 

interclass connection: subclass 
format is positive integer 



E10CD_PEESSDRE 

interclass connection: 
specified 



subclass 



EYE_CCNDITIOH 

interclass connection: subclass 
specified 

EAE_CCNDITION 

interclass connection: subclass 
specified 



IRTEENAL CONDITICH . 

intercXass connection, 
specified 



subclass 



EEALTH_STATOS 

interclass connection: subclass 
format is 2 digit number • 



IflNGUAGES 

interclass connection: subclass 
specified 

lANGUAGE CAPABIIITY 

intercXass connection; subclass 
format is 1 digit number 



mill CODE 

inXerclass connection: subclass 
specified 

DMT NAiMES 

inXerclass connection; subclass 



of 

of 

of 

of 

of 

of 

of 

of 

of 

of 

of 

of 



STRINGS 
STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS where 

STRINGS 



DNIT CAT 

inXerclass connection: subclass of STRINGS where 
format is 3 characters: COR, DIV, BRI, REG, 
ETE 



Figure A. 9 Domains of Attributes (cont’d). 
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DHII LOCATION 

iD^erclass connection; subclass of STRINGS where 
specified 

ONIT FDNC 

inferclass connection: subclass of STRINGS where 
format is 6 characters 

REQDEST NO 

interclass connection: subclass of STRINGS where 
format is 6 digit number 



Figure A. 10 Domains of Attributes (cont*d). 
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4PPEHCII B 

SAMPLE BELAHONS FOB PEESONNEL DATABASE 



This Appendix shews sample relations of the Personnel 
Database, which are used to iaplement. The implementaticn of 
this database is based on these sample relations. 

1 • delation OFFICER : 



UFI> SELECT » 

2 FS^OM OFFICES; 



mo 


RAN< 


3NAM£ 


SEX 


3RI*-6RAN 


SEC^-BRAN 


27363 


c ao t 


Johnson 


n 


a r t i 1 1 


0 i 1 0 1 


1 223<9 


i»a i 


rnander 


n 


i n f t ry 


soe f c 


32^58 


1 1 t 


4oob i n s 


f 


a i rde f 


ado 


iJ35^6 


21 t 


S m i t h 


m 


ne d 1 c 


oi 1 0 r 


1 099Q 


Icol 


3 ro«n 


n 


i n f t rv 


ado 


35768 


1 1 1 


3r ^enoerq 


n 


si :jc 0 r 


0 1 1 0 t 


2^364 


caoc 


Janes 


n 


n 1 1 e nq 


so«^ f c 


16745 


•na j 


Le 1 dh t on 


n 


f i n a nc 


ado 


10742 


C 0 1 


Stone 


n 


0 r dn an 


a r t i 1 1 



^ r «c or s s 1 *c t e'l . 



2. Eela tio n UNIT: 



UFI> SELECT * 

2 FROM unit; 



UCODE 


UNAv^E 




UC AT 


JLDC 


SU»*-UNI T 


dFUNC 


OlOIV 


1st Inf 


0 i V 


d i V 


Ft ,Ri levrKS 


04ARM 


CO noa 


043RG 


4th Art 


8 r q 


b r g 


^t«Ri levfKS 


OUlV 


consu 


6aOE? 


64th 3rd 


Deoo t 


deo 


Ft .Ri lev#KS 


OlOI V 


conse 


1 2H0S 


I2th Fd 


Hoso 


hoso 


f“t .Ri 1 evrKS 


OIDI V 


COTtSP 


02AVI 


2nd Avia 


Jn i t 


req 


Ft . Gordon , GA 


03DI V 


C onoa 


07SGP 


7th Soe 


Fes Go 


ot 


Ft . 3r aqq , NC 


820IV 


conoa 


20A3T 


20th 4irdef 3t 


bt 


Ft. Hood F T X 


02DIV 


C on s U 


03E3N 


3rd Enq 


an 


bn 


Ft . Hood F r X 


02DI V 


C ono a 


0201 V 


2nd Inf 


0 i V 


d i V 


F t . H ood F T X 


07ARM 


c onba 



S records selected 



3* Relation L.EDDCATION; 



UFI> SELECT * 

2 FROM A*-eDUCAriON; 



A8RAN 


AOEG 


AID 


UNI V 


:o*TE 


math 


as 


27363 


JCLA.CA 


06-AUG- 


1 aw 


8A 


1223R 


Ru rdue » I N 


30-JUL- 


ee 


8S 


32^58 


Seat t 1 e# V A 


21-3EP- 


den t 


0S 


43596 


3erke 1 ey »C A 


25-MAY- 


mngt 


8A 


10999 


Loyo 1 a » I L 


01-JUL- 


cs 


MS 


1 0999 


NPGS.CA 


•07-OEC- 


ee 


8S 


35768 


R i c e / T X 


06-mAY- 


cons 


8S 


29364 


MIT.MA 


09-OEC- 


ee 


MS 


29564 


0hio»0N 


10-JUL- 


mngt 


BA 


16745 


Co me 1 1 / NY 


30-SEP- 


me 


0S 


1 0 792 


Rutgers# NJ 


31-AUG- 


ee 


MS 


10792 


NPGS.CA 


01 -MAR- 



13 records selected. 



Eolation M^EDIJC^ION: 



UFJ> SELECT 

2 FROM M#.E0UCATI0N 

3 ORDER by CCODEA.CGRAOE; 



CCOOEA MEI3 CGRADE CDATE 



AA 1 02 


43596 




1 2-JUL-94 


A0002 


32459 


A 


23-N0V-92 


AS003 


27363 


8^ 


1 3-APR-77 


CS302 


32459 


B + 


26-0CT-94 


CS509 


1 0999 


A* 


31-JAN-77 


HS706 


43596 


A 


22-JUN-02 


I A076 


167zi5 


A- 


22-N0V-76 


IS005 


10999 


A 


1 i-nci-70 


IS005 


12239 


A- 


30-SE®-72 


OC092 


1 0792 


A- 


01 -OEC-69 


SS002 


35760 


B + 


26-FEB-82 



11 records selected* 



75 

70 

80 

-80 

68 

73 

•80 

•7R 

85 

75 

65 

•70 
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5 - Rela tio n M COU RSES : 



lifl> SELECT • 

2 fsoM m^c3u;?ses; 



CC00E3 


CL3C3 


CTITLE 


CCESC 


CDUn 


A5003 


r t .Si M , DK 


a r t i 1 1 e r y 


A r ny 


^ield Aptillerv School 


-8 


AA102 


rt .^JC«er,AL 


aviation 


A r ^ y 


Aviation Sc noo 1 


5? 


A0002 


rt.31 iss#TX 


a i r oe t 


A r*»vy 


Air Defense School 


3o 


CS302 


'*on t e r • V , C A 


ado 


Ado 


Officer Course 


1 3 


CS50Q 


p't .r^arri son, I^4 


ado 


AdO 


Officer Course 


1 3 


I A076 


*t .Hapri Son# I. ‘4 


a d n i n 


Ins. 


for Adniniscrstion 


30 


IS005 


Ft .3en-»i nq,GA 


i n f an t r Y 


A p*^ V 


Inf ant ry Scnoo 1 


-e 


H5706 


Ft.'^ouston.TX 


n e a I t n 


Ac a . 


of deeltn Sci. 


5o 


OC092 


Aberdeen #'^0 


0 r dc h e •• 


A p*!^ y 


Oro.and Cnen.Scnool 




5S002 


Ft. Gor con , G A 


s i gna 1 


A pn V 


Signal 3c ^ oo 1 


50 



10 records selected. 



illation LANG DAG S: 



u?l> select . 

2 FS0“ LiN3U»G£; 



^language 


FID LDE 


GREE 


ger-'an 


273a3 


0 


f r enc S 


1 2239 


3 


r js 3 i an 


1 2239 


7 


it 0 r e a n 


1 s795 


2 


german 


3576S 


5 


t j r ic i s n 


32958 


3 


6 records 


sel scteO. 
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7. Gelation MEDICiL; 



UFI> SELECT * 

2 FROM medical; 



REPNO HID ROATE EYECOND EARCOND HSTAT OTHERS 



98381-7 


12239 


30-NOV-81 


0 


0 


0 


. 13282-5 


32a58 


01 -4AR-82 


12 


1 1 


2 


2a582-6 


a3596 


30-AUG-82 


0 


1 1 


1 


3758a. 1 


27363 


07-JUN-aa 


1 1 


0 


1 


a838a.3 


35768 


31-AUG-84 


•10 


0 


1 


12885-a 


29364 


06-HAR-a5 


0 


0 


0 


20985-6 


167a5 


1 a-APR-85 


1 1 


1 1 


2 


- 2a580-0 


1 0999 


1 7-NOV-80 


22 


0 


2 


37580-8 


1 0792 


06-OEC-80 


45 


22 


6 


25681 -2 


27363 


04-OCT-81 


0 


0 


0 



to records selected. 



8- Rela tio n ASSI GNME NT: 



UFI> SELECT . 

2 FROM ASSIGNMENT; 



AMID 


AeUCOOE 


ORDERNO 


ASGDATE 


1 0792 


09BRG 


038165-1 


OI-SEP-66 


1 0999 


OtOIV 


327467-8 


24-SEP-69 


1 6745 


OtOIV 


456277-3 


29-0EC-77 


27363 


OR0RG 


321578-7 


12-SEP-78 


29364 


saOEP 


593879-5 


08-MAR-79 


12239 


0201 V 


491373-6 


30-OCT-75 


32458 


aOABT 


482683-2 


1 O-JAN-83 


43596 


1 2HOS 


321782-4 


1 1 -4 JG-82 


35768 


OIOIV 


152282-9 


0 1 -APR-82 


10792 


02DI V 


324871-5 


1 1 -J AN-71 


10999 


02DIV 


1 1 8273-3 


30-AUG-73 


1 0792 


daOEP 


324678-1 


15-APR-78 



12 records selected. 
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5* Eolation ASGEJ2: 



UFI> SELECT • 

2 FROM ASGSEQ; 



R«-UC00E 




REODATE 




R^^PRIBR 


R^SEC3R 


R^ACABR 


r^miled 


r^hstat 


r^UMOrPERS 
















12H03 


o3ioaa-3 

2 


30-0EC-aa 


-na i 


f i nanc 


ado 


mngt 


IA076 


a 


20ABT 


922185-7 

1 


Ob-MAR-85 


cao t 


ar t i t 1 


pilot 


ee 


AS003 


2 


20SGP 


327805-a 


27-APR-85 


^a i 


> n f t r V 


soe f c 


1 a 


IS005 


0 



I 
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